導入ガイド - suse enterprise storage 6€¦ · 目次このガイドについて x i suse...

導入ガイド

SUSE Enterprise Storage 6

導入ガイドSUSE Enterprise Storage 6著者: Tomáš Bažant、Jana Haláčková、Alexandra Settle、Sven Seeberg

発行日: 22/05/2020

SUSE LLC

1800 South Novell Place

Provo, UT 84606

USA

https://documentation.suse.com

著作権 © 2020 SUSE LLC

Copyright © 2016, RedHat, Inc, and contributors.

本ドキュメントのテキストと図はCreative Commons Attribution-Share Alike 4.0 International (「CC-BY-

SA」)に従ってライセンスされています。CC-BY-SAの説明については、http://creativecommons.org/licenses/

by-sa/4.0/legalcode で参照できます。CC-BY-SAに従い、本ドキュメントまたはその翻案を配布する場合は、

オリジナルバージョンのURLを明記する必要があります。

Red Hat、Red Hat Enterprise Linux、Shadowmanロゴ、JBoss、MetaMatrix、Fedora、Infinityロゴ、および

RHCEは、米国ならびに他の国で登録済みのRed Hat, Inc.の商標です。Linux®は、Linus Torvaldsの米国な

らびに他の国における登録商標です。Java®は、Oracleまたはその関連会社、あるいはその両方の登録商標で

す。XFS®は、Silicon Graphics International Corp.またはその子会社の米国または他の国、あるいはその両

方における商標です。その他すべての商標は、それぞれの所有者の所有物です。

SUSEの商標については、http://www.suse.com/company/legal/ を参照してください。その他の製品名およ

び会社名は、各社の商標または登録商標です。商標記号(®、 ™など)は、SUSEおよび関連会社の商標を示しま

す。アスタリスク(*)は、第三者の商標を示します。

https://documentation.suse.com

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://www.suse.com/company/legal/

本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証す

るものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任

を負いかねます。

目次

このガイドについて x

I SUSE ENTERPRISE STORAGE 1

1 SUSE Enterprise Storage 6とCeph 21.1 Cephの特徴 2

1.2 コアコンポーネント 3

RADOS 3 • CRUSH 4 • Cephのノードとデーモン 5

1.3 ストレージの構造 6

プール 6 • 配置グループ 7 • 例 7

1.4 BlueStore 8

1.5 追加情報 10

2 ハードウェア要件と推奨事項 11

2.1 複数のアーキテクチャの設定 11

2.2 最小クラスタ設定 11

2.3 オブジェクトストレージノード 12

最小要件 12 • 最小ディスクサイズ 12 • BlueStoreのWALおよびDBデバ

イスの推奨サイズ 13 • OSDジャーナルでのSSDの使用 13 • 推奨される

ディスクの最大数 14

2.4 モニタノード 14

2.5 Object Gatewayノード 15

2.6 Metadata Serverノード 15

2.7 Salt Master 15

2.8 iSCSIノード 15

iv 導入ガイド

2.9 ネットワーク要件 16

実行中のクラスタへのプライベートネットワークの追加 16 • 異なるサブネット上

のモニタノード 17

2.10 命名の制限 17

2.11 OSDとモニタでの1台のサーバの共有 18

2.12 運用クラスタの推奨設定 18

2.13 SUSE Enterprise Storage 6とその他のSUSE製品 19

SUSE Manager 19

3 管理ノードのHAセットアップ 20

3.1 管理ノードのHAクラスタの概要 20

3.2 管理ノードによるHAクラスタの構築 21

4 ユーザの特権とコマンドプロンプト 23

4.1 Salt/DeepSea関連のコマンド 23

4.2 Ceph関連のコマンド 23

4.3 一般的なLinuxコマンド 24

4.4 追加情報 24

II クラスタの展開とアップグレード 25

5 DeepSea/Saltを使用した展開 265.1 リリースノートの確認 26

5.2 DeepSeaの概要 27

組織と重要な場所 28 • ミニオンのターゲット設定 29

5.3 クラスタの展開 31

5.4 DeepSea CLI 40

DeepSea CLI: モニタモード 40 • DeepSea CLI: スタンドアロンモード 41

5.5 設定とカスタマイズ 43

policy.cfgファイル 43 • DriveGroups 48 • カスタム設定を使用し

たceph.confの調整 57

v 導入ガイド

6 古いリリースからのアップグレード 58

6.1 アップグレード前に考慮すべき点 58

6.2 クラスタデータのバックアップ 62

6.3 ntpdからchronydへの移行 62

6.4 アップグレード前にクラスタにパッチを適用 64

必要なソフトウェアリポジトリ 64 • リポジトリステージングシステム 64 • ク

ラスタ全体への最新パッチの適用 65

6.5 現在の環境の検証 65

6.6 クラスタの状態の確認 66

6.7 CTDBクラスタのオフラインアップグレード 67

6.8 ノード単位のアップグレード — 基本的な手順 67

インストーラDVDを使用したノードの手動アップグレード 68 • SUSE

Distribution Migration Systemを使用したノードのアップグレード 70

6.9 管理ノードのアップグレード 71

6.10 Ceph Monitor/Ceph Managerノードのアップグレード 72

6.11 Metadata Serverのアップグレード 73

6.12 Ceph OSDのアップグレード 74

6.13 BlueStoreへのOSDのマイグレーション 77

6.14 アプリケーションノードのアップグレード 79

6.15 policy.cfgの更新、およびDeepSeaを使用したCephダッシュボードの展開 79

6.16 プロファイルベースの展開からDriveGroupsへのマイグレーション 82

現在のレイアウトの分析 82 • 現在のレイアウトに一致するDriveGroupsの作

成 82 • OSDの展開 83 • より複雑なセットアップ 84

7 デフォルト設定のカスタマイズ 85

7.1 カスタマイズされた設定ファイルの使用 85

展開手順の無効化 85 • 展開手順の置き換え 86 • 展開手順の変

更 87 • 展開ステージの変更 88 • ステージ0での更新と再起動 90

vi 導入ガイド

7.2 検出された設定の変更 91

Cephクラスタ展開のためのIPv6の有効化 93

III 追加のサービスのインストール 94

8 データにアクセスするためのサービスのインストール 95

9 Ceph Object Gateway 96

9.1 Object Gatewayの手動インストール 96

Object Gatewayの設定 97

10 iSCSI Gatewayのインストール 103

10.1 iSCSIブロックストレージ 103

LinuxカーネルiSCSIターゲット 104 • iSCSIイニシエータ 104

10.2 ceph-iscsiに関する一般情報 105

10.3 展開に関する考慮事項 106

10.4 インストールと環境設定 107

CephクラスタへのiSCSI Gatewayの展開 107 • RBDイメージの作

成 107 • iSCSI経由でのRBDイメージのエクスポート 108 • 認証とアクセス

制御 109 • 詳細設定 111

10.5 tcmu-runnerを使用したRADOS Block Deviceイメージのエクスポート 114

11 CephFSのインストール 115

11.1 CephFSでサポートされるシナリオとガイド 115

11.2 Ceph Metadata Server 116

Metadata Serverの追加 116 • Metadata Serverの設定 116

11.3 CephFS 121

CephFSの作成 122 • MDSのクラスタサイズ 123 • MDSクラスタと更

新 124 • ファイルのレイアウト 124

vii 導入ガイド

12 NFS Ganeshaのインストール 130

12.1 準備 130

一般情報 130 • 要件の概要 131

12.2 インストールの例 131

12.3 高可用性のアクティブ-パッシブ設定 132

基本的なインストール 132 • リソースのクリーンアップ 134 • Pingリソースの

設定 135 • NFS Ganesha HAとDeepSea 135

12.4 アクティブ-アクティブ設定 136

前提条件 136 • NFS Ganeshaの設定 137 • クラスタ猶予データベースへ

の入力 138 • NFS Ganeshaサービスの再起動 139 • 結論 139

12.5 詳細情報 139

IV SUSE CAAS PLATFORM 4上でのクラスタの展開(技術プレビュー) 140

13 SUSE CaaS Platform 4 Kubernetesクラスタ上のSUSEEnterprise Storage 6 141

13.1 注意事項 141

13.2 前提条件 141

13.3 Rookマニフェストの取得 141

13.4 インストール 142

設定 142 • Rookオペレータの作成 143 • Cephクラスタの作成 144

13.5 Kubernetesワークロード用ストレージとしてのRookの使用 145

13.6 Rookのアンインストール 145

A アップストリーム「Nautilus」ポイントリリースに基づくCeph保守更新 147

用語集 150

B マニュアルの更新 153

B.1 SUSE Enterprise Storage 6ドキュメントの保守更新 153

viii 導入ガイド

B.2 2019年6月(SUSE Enterprise Storage 6のリリース) 154

ix 導入ガイド

このガイドについて

SUSE Enterprise Storage 6は、SUSE Linux Enterprise Server 15 SP1を拡張したもので

す。Ceph (http://ceph.com/ )ストレージプロジェクトの機能に、SUSEのエンタープライズエンジ

ニアリングとサポートが組み合わされています。SUSE Enterprise Storage 6により、IT組織は、コモ

ディティハードウェアプラットフォームを使用して多様な使用事例に対応できる分散ストレージアーキテ

クチャを展開できます。

このガイドは、主にCephインフラストラクチャの管理に焦点を当てており、読者がSUSE Enterprise

Storage 6の概念を理解するのに役立ちます。さらに、CephをOpenStack、KVMなどの他の関連ソ

リューションと共に使用する方法についても実例を交えて説明します。

このマニュアル中の多くの章に、他の資料やリソースへのリンクが記載されています。それらは、システ

ム上で参照できる追加ドキュメントやインターネットから入手できるドキュメントなどです。

ご使用製品の利用可能なマニュアルと最新のドキュメントアップデートの概要については、http://

www.suse.com/documentation を参照してください。

1 利用可能なマニュアルこの製品の次のマニュアルを入手できます。

『管理ガイド』

このガイドは、一般的にインストール後に実行するさまざまな管理タスクについて説明します。さら

に、Cephを libvirt 、Xen、KVMなどの仮想化ソリューションと統合する手順や、クラスタに保

存されているオブジェクトにiSCSIやRADOSゲートウェイ経由でアクセスする方法についても紹

介します。

導入ガイド

Cephクラスタと、すべてのCeph関連サービスのインストール手順を、順を追って説明します。さ

らに、Cephクラスタの基本構造と、関連する用語についても説明します。

これらの製品マニュアルのHTMLバージョンは、インストールしたシステムの /usr/share/doc/

manualにあります。マニュアルの最新の更新版はhttp://www.suse.com/documentation に掲

載されており、ここからご使用の製品のマニュアルを複数のフォーマットでダウンロードできます。

2 フィードバック次のフィードバックチャネルがあります。

x 利用可能なマニュアル SES 6

http://ceph.com/

http://www.suse.com/documentation



バグと機能拡張の要求

ご使用の製品に利用できるサービスとサポートのオプションについては、http://

www.suse.com/support/ を参照してください。

製品コンポーネントのバグを報告するには、http://www.suse.com/support/ からNovell

Customer Centerにログインし、［マイサポート］［サービス要求］の順に選択します。

ユーザからのコメント

本マニュアルおよびこの製品に含まれているその他のマニュアルについて、皆様のご意見やご要

望をお寄せください。オンラインドキュメントの各ページの下にあるユーザコメント機能を使用する

か、またはhttp://www.suse.com/documentation/feedback.html にアクセスして、コメント

を入力してください。

メール

この製品のドキュメントについてのフィードバックは、 [email protected]宛のメールでも送信で

きます。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してくださ

い。エラーの報告または機能拡張の提案では、問題について簡潔に説明し、対応するセクション

番号とページ(またはURL)をお知らせください。

3 マニュアルの表記規則本書では、次の書体を使用しています。

/etc/passwd : ディレクトリ名とファイル名

placeholder : placeholderは、実際の値で置き換えられます

PATH :環境変数PATH

ls 、 --help :コマンド、オプション、およびパラメータ

user :ユーザまたはグループ

Alt 、 Alt – F1 :使用するキーまたはキーの組み合わせ、キーはキーボード上と同様、大文字で

表示される

［ファイル］、［ファイル］［名前を付けて保存］: メニュー項目、ボタン

Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章への参照で

す。

xi マニュアルの表記規則 SES 6

http://www.suse.com/support/



http://www.suse.com/documentation/feedback.html

4 本マニュアルの作成について本書は、DocBook(http://www.docbook.org を参照)のサブセットであるGeekoDocで作成され

ています。XMLソースファイルは xmllintによって検証され、 xsltprocによって処理され、Norman

Walshによるスタイルシートのカスタマイズ版を使用してXSL-FOに変換されました。最終的なPDF

は、ApacheのFOPまたはRenderXのXEPでフォーマットされている可能性があります。本書の生成

に使用されたオーサリングおよび発行ツールは、 dapsパッケージで利用可能です。DocBook DAPS

(Authoring and Publishing Suite)はオープンソースソフトウェアとして開発されています。詳細につ

いては、http://daps.sf.net/ を参照してください。

5 Cephの貢献者Cephプロジェクトとそのドキュメントは、数百人の貢献者と組織の作業の結果です。詳細について

は、https://ceph.com/contributors/ を参照してください。

xii 本マニュアルの作成について SES 6

http://www.docbook.org

http://daps.sf.net/

https://ceph.com/contributors/

I SUSE Enterprise Storage

1 SUSE Enterprise Storage 6とCeph 2

2 ハードウェア要件と推奨事項 11

3 管理ノードのHAセットアップ 20

4 ユーザの特権とコマンドプロンプト 23

1 SUSE Enterprise Storage 6とCeph

SUSE Enterprise Storage 6は、スケーラビリティ、信頼性、およびパフォーマンスを目的として設計

された、Cephテクノロジに基づく分散ストレージシステムです。Cephクラスタは、Ethernetなどの一般

的なネットワーク内にあるコモディティサーバで実行できます。クラスタは、数千台のサーバ(以降、ノード

と呼びます)とペタバイトの域にまで容易に拡張できます。データを保存および取得するためのアロケー

ションテーブルを持つ従来のシステムとは異なり、Cephは決定的アルゴリズムを使用してデータの記

憶域を割り当て、集中化された情報構造を持ちません。Cephでは、Storage Cluster内でのハードウェ

アの追加や削除は、例外ではなく標準の動作であると想定されています。Cephクラスタは、データの

分散と再分散、データの複製、障害検出、回復などの管理タスクを自動化します。Cephは自己修復機

能と自己管理機能の両方を備えているため、管理と予算のオーバーヘッドが削減されます。

この章では、SUSE Enterprise Storage 6の大まかな概要と、最も重要なコンポーネントについて簡

単に説明します。

ヒントSUSE Enterprise Storage 5から、クラスタの展開方法はDeepSeaのみになっています。展

開プロセスの詳細については、第5章「DeepSea/Saltを使用した展開」を参照してください。

1.1 Cephの特徴Ceph環境には次のような特徴があります。

スケーラビリティ

Cephは数千台のノードにまで拡張でき、ペタバイトの域のストレージを管理できます。

コモディティハードウェア

Cephクラスタを実行するのに特別なハードウェアは必要ありません。詳細については、第2章

「ハードウェア要件と推奨事項」を参照してください。

自己管理

Cephクラスタは自己管理型です。ノードが追加または削除された場合、あるいはノードに障害が

発生した場合、クラスタは自動的にデータを再分散します。過負荷状態のディスクを認識する機

能もあります。

SPOF (Single Point of Failure)を排除

クラスタ内のノードが重要な情報を単独で保存することはありません。冗長性の数は設定が可能

です。

2 Cephの特徴 SES 6

オープンソースのソフトウェア

Cephは、特定のハードウェアやベンダーとは無関係のオープンソースソフトウェアソリューション

です。

1.2 コアコンポーネントCephの能力を最大限活用するには、その基本的なコンポーネントと概念を理解する必要があります。

このセクションでは、他の章で頻繁に参照されるCephの機能をいくつか紹介します。

1.2.1 RADOS

Cephの基本コンポーネントは「RADOS (Reliable Autonomic Distributed Object Store) 」と呼

ばれます。これは、クラスタに保存されるデータの管理を受け持ちます。通常、Ceph内のデータはオブ

ジェクトとして保存されています。各オブジェクトはIDとデータで構成されます。

RADOSは、保存オブジェクトへのアクセス方法として次の方法を備えており、さまざまな使用事例に対

応します。

Object Gateway

Object Gatewayは、RADOS Object StoreのHTTP RESTゲートウェイです。これによ

り、Cephクラスタに保存されているオブジェクトへの直接アクセスが可能になります。

RADOS Block Device

RBD (RADOS Block Device)には他のブロックデバイスと同じようにアクセスできます。たとえ

ば、仮想化を行う場合、RBDと libvirtを組み合わせて使用できます。

CephFS

Ceph File SystemはPOSIX互換のファイルシステムです。

librados

libradosは、Storage Clusterを直接操作できるアプリケーションを作成するためのライブラリ

で、さまざまなプログラミング言語で使用できます。

Object GatewayとRBDは libradosを使用するのに対し、CephFSはRADOSと直接対話しま

す。図1.1「Ceph Object Storeのインタフェース」を参照してください。

3 コアコンポーネント SES 6

RADOS

図 1.1: CEPH OBJECT STOREのインタフェース

1.2.2 CRUSH

Cephクラスタの中核を成すのは「CRUSH」アルゴリズムです。CRUSHは「Controlled Replication

Under Scalable Hashing」の略語です。CRUSHはストレージの割り当てを扱う機能で、指定が必要

なパラメータは比較的少なくなっています。つまり、オブジェクトの保存位置を計算するのに必要な情報

はごくわずかです。そのパラメータは、ヘルス状態を含むクラスタの現在のマップ、管理者定義の配置

ルール、および保存または取得する必要があるオブジェクトの名前です。この情報により、Cephクラス

タ内のすべてのノードは、オブジェクトとそのレプリカが保存されている場所を計算できます。このため、

データの読み書きが非常に効率化されます。CRUSHは、データをクラスタ内のすべてのノードに均等

に分散しようとします。

「CRUSHマップ」には、クラスタにオブジェクトを保存するために、すべてのストレージノードと管理者定

義の配置ルールが記述されています。CRUSHマップは階層構造を定義し、その階層構造は通常、クラ

スタの物理構造に対応します。たとえば、データが含まれるディスクがホストにあり、ホストがラックに格

納されているとします。さらに、ラックは複数の列に収容されていて、ラック列はデータセンターにあると

します。この構造を使用して「障害ドメイン」を定義できます。Cephは、それに従ってレプリケーションが

特定の障害ドメインの異なるブランチに保存されるようにします。

障害ドメインがラックに設定されている場合、オブジェクトのレプリケーションは異なるラックに分散され

ます。これによって、ラック内のスイッチの障害によって発生する停止を緩和できます。1台の配電ユニッ

トで1つのラック列に電力を供給している場合は、障害ドメインを列に設定できます。配電ユニットに障

害が発生しても、引き続き他の列で複製されたデータを利用できます。

4 CRUSH SES 6

1.2.3 Cephのノードとデーモン

Cephでは、ノードとはクラスタを形成しているサーバです。ノードでは複数の種類のデーモンを実

行できます。各ノードで実行するデーモンは1種類だけにすることをお勧めします。ただし、Ceph

Managerデーモンは例外で、Ceph Monitorと一緒に配置できます。各クラスタには、少なくともCeph

Monitor、Ceph Manager、およびCeph OSDデーモンが必要です。

管理ノード

「管理ノード」は、Salt Masterサービスが動作しているCephクラスタノードです。管理ノード

は、Salt Minionサービスに対してクエリと命令を行うことで他のクラスタノードを管理するの

で、Cephクラスタの中心となる場所です。管理ノードには通常、ほかのサービスも含まれま

す。たとえば、CephダッシュボードWeb UIと、「Prometheus」監視ツールキットを利用する

「Grafana」ダッシュボードなどです。

Ceph Monitor

「Ceph Monitor」(多くの場合、「MON」と省略)ノードは、クラスタのヘルス状態に関する情報、

すべてのノードのマップ、およびデータ分散ルールを維持します(1.2.2項「CRUSH」を参照してく

ださい)。

障害または衝突が発生した場合、クラスタ内のCeph Monitorノードは、どの情報が正しいか

を多数決で決定します。必ず多数決が得られるように、奇数個(少なくとも3個以上)のCeph

Monitorノードを設定することをお勧めします。

複数のサイトを使用する場合、Ceph Monitorノードは奇数個のサイトに分散する必要がありま

す。サイトあたりのCeph Monitorノードの数は、1つのサイトに障害が発生したときに、50%を超

えるCeph Monitorノードの機能が維持される数にする必要があります。

Ceph Manager

Ceph Manager (MGR)は、クラスタ全体から状態情報を収集します。Ceph Managerデーモン

はモニタデーモンと共に動作します。追加のモニタリング機能を提供し、外部のモニタリングシス

テムや管理システムとのインタフェースとして機能します。

Ceph Managerには、動作確認以外の追加設定は必要ありません。DeepSeaを使用して別個

の役割として展開できます。

Ceph OSD

「Ceph OSD」は、「オブジェクトストレージデバイス」を処理するデーモンです。OSDは、物理ス

トレージユニットまたは論理ストレージユニット(ハードディスクまたはパーティション)になります。

オブジェクトストレージデバイスは、物理ディスク/パーティションにも、論理ボリュームにもできま

す。このデーモンはほかにも、データのレプリケーションや、ノードが追加または削除された場合の

リバランスも処理します。

Ceph OSDデーモンは、モニタデーモンと通信して、他のOSDデーモンの状態を監視デーモンに

提供します。

5 Cephのノードとデーモン SES 6

CephFS、Object Gateway、NFS Ganesha、またはiSCSI Gatewayを使用するには、追加のノード

が必要です。

MDS (メタデータサーバ)

Metadata ServerはCephFSのメタデータを保存します。MDSを使用することで、 lsなどの基

本的なファイルシステムコマンドを、クラスタを過負荷状態にせずに実行できます。

Object Gateway

Object Gatewayは、RADOS Object StoreのHTTP RESTゲートウェイです。OpenStack

SwiftおよびAmazon S3と互換性があり、独自のユーザ管理機能を持ちます。

NFS Ganesha

NFS Ganeshaは、Object GatewayまたはCephFSにNFSアクセスを提供します。カーネル空

間ではなくユーザ空間で動作し、Object GatewayまたはCephFSと直接対話します。

iSCSI Gateway

iSCSIは、クライアントからリモートサーバ上のSCSIストレージデバイス(ターゲット)にSCSIコマン

ドを送信できるようにするストレージネットワークプロトコルです。

Sambaゲートウェイ

Sambaゲートウェイは、CephFSに保存されているデータにSAMBAでアクセスできるようにしま

す。

1.3 ストレージの構造

1.3.1 プール

Cephクラスタに保存されるオブジェクトは「プール」に配置されます。プールは、外部環境に対してはク

ラスタの論理パーティションを表します。各プールに対して一連のルールを定義できます。たとえば、各

オブジェクトのレプリケーションがいくつ存在する必要があるかなどを定義できます。プールの標準設

定を「複製プール」と呼びます。

通常、プールにはオブジェクトが含まれていますが、RAID 5と同様の動作をするように設定することも

できます。この設定の場合、オブジェクトは追加のコーディングチャンクと共にチャンクで保存されます。

コーディングチャンクには冗長な情報が含まれます。データとコーディングチャンクの数は管理者が定

義できます。この設定の場合、プールは「イレージャコーディングプール」と呼ばれます。

6 ストレージの構造 SES 6

1.3.2 配置グループ

「配置グループ」(PG)は、プール内でデータを分散するために使用されます。プールの作成時に、一定

数の配置グループが設定されます。配置グループは、オブジェクトをグループ化するために内部的に

使用され、Cephクラスタのパフォーマンスにおける重要な要因です。オブジェクトのPGはオブジェクト

の名前によって決定されます。

1.3.3 例

このセクションでは、Cephのデータ管理の仕組みを簡単な例で説明します(図1.2「小規模なCeph

の例」を参照してください)。この例は、Cephクラスタの推奨設定を表すものではありません。この

ハードウェアセットアップは、3つのストレージノードまたはCeph OSD (ホスト1 、ホスト2 、ホス

ト3 )で構成されます。各ノードにはハードディスクが3つあり、それぞれがOSDとして使用されます

( osd.1〜 osd.9 )。この例では、Ceph Monitorノードを無視しています。

注記: Ceph OSDとOSDの違い「Ceph OSD」または「Ceph OSDデーモン」は、ノード上で実行されるデーモンを指すのに対

し、「OSD」という語はそのデーモンが対話する論理ディスクを指します。

クラスタにはプールAとプールBの2つのプールがあります。プールAはオブジェクトを2回だけ複製する

のに対し、プールBの災害耐性はより重要であるため、各オブジェクトのレプリケーションを3つ保持しま

す。

たとえばREST API経由でアプリケーションがオブジェクトをプールに配置すると、プールとオブジェク

ト名に基づいて配置グループ( PG1〜 PG4 )が選択されます。続いて、CRUSHアルゴリズムにより、オブ

ジェクトが含まれている配置グループに基づいて、オブジェクトを保存するOSDが計算されます。

この例では、障害ドメインはホストに設定されています。これにより、オブジェクトのレプリケーションが

確実に別のホストに保存されるようにします。プールに設定されているレプリケーションレベルに応じて、

オブジェクトは、配置グループによって使用される2つまたは3つのOSDに保存されます。

オブジェクトを書き込むアプリケーションは、プライマリCeph OSDである1つのCeph OSDとのみ対話

します。プライマリCeph OSDはレプリケーションを処理し、他のすべてのOSDがオブジェクトを保存し

たら、書き込みプロセスの完了を確認します。

osd.5に障害が発生した場合、 PG1のすべてのオブジェクトは osd.1で引き続き利用可能で

す。OSDに障害が発生したことをクラスタが認識するとすぐに、別のOSDが処理を引き継ぎます。この

例では、 osd.4が osd.5の代わりとして使用されます。その後、 osd.1に保存されているオブジェクト

が osd.4に複製され、レプリケーションレベルが復元されます。

7 配置グループ SES 6

図 1.2: 小規模なCEPHの例

新しいOSDを持つ新しいノードがクラスタに追加されると、クラスタマップが変更されます。それに従っ

て、CRUSH機能はオブジェクトに対して別の場所を返します。新しい場所を受け取ったオブジェクト

は、別の場所に移動されます。このプロセスにより、すべてのOSDがバランス良く使用されます。

1.4 BlueStoreSUSE Enterprise Storage 5から、BlueStoreは新しくCephのデフォルトのストレージバックエンドに

なりました。BlueStoreはFileStoreよりもパフォーマンスが高く、データの完全なチェックサムや組み込

みの圧縮機能を備えています。

BlueStoreは、1つ、2つ、または3つのいずれかのストレージデバイスを管理します。最もシンプルな

ケースでは、BlueStoreは1つのプライマリストレージデバイスを使用します。通常、ストレージデバイス

は、次の2つの部分にパーティション分割されます。

1. BlueFSという名前の小容量のパーティション。RocksDBで必要な、ファイルシステムに似た機

能を実装します。

2. 通常、デバイスの残りの部分は、その部分を占有する大容量のパーティションになります。これは

BlueStoreによって直接管理され、実際のデータがすべて含まれます。通常、このプライマリデバ

イスは、データディレクトリ内ではブロックシンボリックリンクで識別されます。

8 BlueStore SES 6

次のように、2つの追加デバイスにわたってBlueStoreを展開することもできます。

「WALデバイス」は、BlueStoreの内部ジャーナルまたは先書きログに使用できます。これは、データ

ディレクトリでは、シンボリックリンク block.walで識別されます。別個のWALデバイスを使用すると役

立つのは、そのデバイスがプライマリデバイスまたはDBデバイスより高速な場合だけです。たとえば、次

のような場合です。

WALデバイスがNVMeで、DBデバイスがSSD、データデバイスがSSDまたはHDDである。

WALデバイスとDBデバイスの両方が別個のSSDで、データデバイスがSSDまたはHDDであ

る。

「DBデバイス」は、BlueStoreの内部メタデータを保存するために使用できます。BlueStore (または埋

め込みのRocksDB)は、パフォーマンスを向上させるため、できる限り多くのメタデータをDBデバイス

上に配置します。ここでも、共有DBデバイスをプロビジョニングすると役に立つのは、そのデバイスがプ

ライマリデバイスより高速な場合だけです。

ヒント: DBサイズの計画DBデバイスが十分なサイズになるよう慎重に計画してください。DBデバイスがいっぱいになる

と、メタデータがプライマリデバイスにあふれ、OSDのパフォーマンスが大きく低下します。

ceph daemon osd.ID perf dumpコマンドを使用して、WAL/DBパーティションがいっぱい

であふれそうかどうかを調べることができます。 slow_used_bytesの値に、あふれているデータ

の量が表示されます。

cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'"db_total_bytes": 1073741824,"db_used_bytes": 33554432,"wal_total_bytes": 0,"wal_used_bytes": 0,"slow_total_bytes": 554432,"slow_used_bytes": 554432,

9 BlueStore SES 6

1.5 追加情報コミュニティプロジェクトとして、Cephには、独自の広範なオンラインヘルプがあります。このマ

ニュアルに記載されていないトピックについては、http://docs.ceph.com/docs/master/ を

参照してください。

S.A. Weil、S.A. Brandt、E.L. Miller、C. Maltzahnによる元のドキュメント『CRUSH:

Controlled, Scalable, Decentralized Placement of Replicated Data』には、Cephの内

部動作に関する有益な洞察が記載されています。特に大規模クラスタを展開する場合には、これ

を一読することをお勧めします。このドキュメントはhttp://www.ssrc.ucsc.edu/papers/weil-

sc06.pdf にあります。

SUSE Enterprise Storageは、SUSE OpenStack以外の配布パッケージで使用できま

す。Cephクライアントは、SUSE Enterprise Storageと互換性があるレベルである必要がありま

す。

注記SUSEはCeph展開のサーバコンポーネントをサポートし、クライアントはOpenStack配布

パッケージベンダーによってサポートされます。

10 追加情報 SES 6

http://docs.ceph.com/docs/master/

http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf

http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf

2 ハードウェア要件と推奨事項

Cephのハードウェア要件は、IOワークロードに大きく依存します。次のハードウェア要件と推奨事項

は、詳細な計画を立てる際の起点と考えてください。

一般的に、このセクションで説明する推奨事項はプロセスごとの推奨事項です。同じマシンに複数のプ

ロセスがある場合は、CPU、RAM、ディスク、およびネットワークの各要件を追加する必要があります。

2.1 複数のアーキテクチャの設定SUSE Enterprise Storageでは、x86とArmの両方のアーキテクチャをサポートしています。各アーキ

テクチャを検討する際は、OSDあたりのコア数、周波数、およびRAMの観点から見ると、サイジングに

関して、CPUアーキテクチャ間に実質的な差異はないことに注意することが重要です。

小型のx86プロセッサ(サーバ以外)と同様に、パフォーマンスの低いArmベースのコアは、特にイレー

ジャコーディングプールに使用する場合は最適なエクスペリエンスを提供できない可能性があります。

2.2 最小クラスタ設定

少なくとも4つのOSDノードと、そのそれぞれに8つのOSDディスクが必要。

3つのCeph Monitorノード(OS専用ドライブ用にSSDが必要)。

iSCSI Gateway、Object Gateway、およびMetadata Serverには、4GBのRAMと4コアの追

加が必要。

Ceph Monitorノード、Object Gatewayノード、およびMetadata Serverノードは冗長展開が必

要。

4GBのRAM、4コア、1TBの容量を備えた別個の管理ノード。これは通常、Salt Master

ノードです。Ceph Monitor、Ceph Manager、Metadata Server、Ceph OSD、Object

Gateway、NFS GaneshaなどのCephサービスおよびゲートウェイは、管理ノードではサポート

されません。

11 複数のアーキテクチャの設定 SES 6

2.3 オブジェクトストレージノード

2.3.1 最小要件

CPUの推奨事項

スピナあたり1つの2GHz CPUスレッド

SSDあたり2つの2GHz CPUスレッド

MVMeあたり4つの2GHz CPUスレッド

独立した10GbEネットワーク(パブリック/クライアントおよびバックエンド)、4つの10GbEが必

須、2つの25GbEを推奨。

必要なRAMの合計 = OSDの数 x (1GB + osd_memory_target ) + 16GB

osd_memory_targetの詳細については、『管理ガイド』、第16章「Cephクラスタの設

定」、16.2.1項「自動キャッシュサイズ」を参照してください。

JBOD設定または個々のRAID-0設定のOSDディスク。

OSDジャーナルはOSDディスクに配置可能.

OSDディスクはSUSE Enterprise Storage専用である必要があります。

オペレーティングシステム専用のディスク/SSD (できればRAID 1設定)。

このOSDホストが、キャッシュ階層化に使用するキャッシュプールの一部をホストする場合、追加

で4GB以上のRAMを割り当てます。

Ceph Monitor、ゲートウェイ、およびMetadata Serverはオブジェクトストレージノードに配置

可能.

ディスクパフォーマンス上の理由から、OSDノードには、仮想マシンではなくベアメタルを使用す

ることをお勧めします。

2.3.2 最小ディスクサイズ

OSD上で実行する必要があるディスク領域には2つのタイプがあります。ディスクジャーナル用の領

域(FileStoreの場合)またはWAL/DBデバイス用の領域(BlueStoreの場合)と、保存データ用のプラ

イマリ領域です。ジャーナル/WAL/DBの最小(デフォルト)の値は6GBです。データ用の最小領域は

5GBです。これは、5GB未満のパーティションには自動的に重み0が割り当てられるためです。

12 オブジェクトストレージノード SES 6

したがって、OSDの最小ディスク領域は11GBになりますが、テスト目的であっても20GB未満のディス

クはお勧めしません。

2.3.3 BlueStoreのWALおよびDBデバイスの推奨サイズ

ヒント: 詳細情報BlueStoreの詳細については、1.4項「BlueStore」を参照してください。

WALデバイス用に4GBを予約することをお勧めします。DBの推奨サイズは、ほとんどのワーク

ロードにおいて64MBです。

WALとDBデバイスを同じディスクに配置する予定の場合は、それぞれに別個のパーティショ

ンを設けるのではなく、両方のデバイスに対して単一のパーティションを使用することをお勧め

します。これにより、CephはDBデバイスをWAL操作にも使用できます。Cephは必要時にのみ

DBパーティションをWALに使用するので、ディスク領域の管理が効率化します。もう1つの利点

は、WALパーティションがいっぱいになる可能性は極めて低く、完全に使い切っていなければ、そ

の領域が無駄になることはなく、DB操作に使用されることです。

DBデバイスをWALと共有するには、WALデバイスを「指定しない」で、DBデバイスのみを指定し

ます。

OSDレイアウトを指定する方法の詳細については、5.5.2項「DriveGroups」を参照してくださ

い。

2.3.4 OSDジャーナルでのSSDの使用

SSD (ソリッドステートドライブ)には可動部品がありません。これは、ランダムアクセス時間と読み込み

レイテンシを短縮すると同時に、データスループットを加速します。SSDの1MBあたりの価格は回転型

ハードディスクの価格より大幅に高いため、SSDは小容量のストレージにのみ適しています。

ジャーナルをSSDに保存し、オブジェクトデータは別個のハードディスクに保存することで、OSDのパ

フォーマンスを大幅に向上することができます。

13 BlueStoreのWALおよびDBデバイスの推奨サイズ SES 6

ヒント: 複数のジャーナルでのSSDの共有ジャーナルデータは比較的少ない使用領域しか占有しないため、1つのSSDディスクに複数の

ジャーナルディレクトリをマウントできます。共有ジャーナルを増やすと、そのたびにSSDディス

クのパフォーマンスが低下するので注意してください。同じSSDディスクでジャーナルを7つ以

上共有することはお勧めしません。NVMeディスクの場合は、13個以上の共有はお勧めしませ

ん。

2.3.5 推奨されるディスクの最大数1台のサーバで、そのサーバで使用できる数だけのディスクを使用できます。サーバあたりのディスク数

を計画する際には、考慮すべき点がいくつかあります。

「ネットワーク帯域幅」サーバのディスクが増えるほど、ディスク書き込み操作のためにネットワー

クカード経由で転送しなければならないデータが増えます。

「メモリ」2GBを超えるRAMは、BlueStoreキャッシュに使用されます。 osd_memory_targetの

デフォルトである4GBを使用すると、回転型メディアに適したキャッシュ開始サイズがシステムに

設定されます。SSDまたはNVMEを使用する場合は、OSDあたりのキャッシュサイズとRAM割り

当てを増やすことを検討します。

「耐障害性」サーバ全体に障害が発生した場合、搭載ディスクの数が多いほど、クラスタが一時

的に失うOSDが増えます。さらに、レプリケーションルールを実行し続けるために、障害が発生し

たサーバからクラスタ内のほかのノードにすべてのデータをコピーする必要があります。

2.4 モニタノード少なくとも3つのCeph Monitorノードが必要です。モニタの数は常に基数(1+2n)である必要が

あります。

4GBのRAM。

4つの論理コアを持つプロセッサ。

特に各モニタノードの /var/lib/cephパスには、SSDか、その他の十分高速なストレージタイプ

を強くお勧めします。ディスクのレイテンシが大きいと、クォーラムが不安定になる可能性がある

ためです。冗長性を確保するには、RAID 1設定で2台のディスクを使用することをお勧めします。

モニタが利用可能なディスク領域をログファイルの増大などから保護するため、モニタプロセスに

は、別個のディスク、または少なくとも別個のディスクパーティションを使用することをお勧めしま

す。

14 推奨されるディスクの最大数 SES 6

各ノードのモニタプロセスは1つだけにする必要があります。

OSDノード、モニタノード、またはObject Gatewayノードを混在させることは、十分なハードウェ

アリソースが利用可能な場合にのみサポートされます。つまり、すべてのサービスの要件を合計す

る必要があります。

複数のスイッチにボンディングされた2つのネットワークインタフェース。

2.5 Object GatewayノードObject Gatewayノードには、6〜8個のCPUコアと32GBのRAM (64GBを推奨)が必要です。同じマ

シンに他のプロセスも配置されている場合、それらの要件を合計する必要があります。

2.6 Metadata ServerノードMetadata Serverノードの適切なサイズは、具体的な使用事例によって異なります。一般的に

は、Metadata Serverが処理する開いているファイルが多いほど、より多くのCPUとRAMが必要にな

ります。最小要件は次のとおりです。

各Metadata Serverドメインに対して3GのRAM。

ボンディングされた2つのネットワークインタフェース。

2個以上のコアを持つ2.5GHzのCPU。

2.7 Salt Master少なくとも4GBのRAMとクアッドコアCPUが必要です。これには、管理ノードでのCephダッシュボード

の実行が含まれます。数百のノードで構成される大規模クラスタでは、6GBのRAMをお勧めします。

2.8 iSCSIノードiSCSIノードには、6〜8個のCPUコアと16GBのRAMが必要です。

15 Object Gatewayノード SES 6

2.9 ネットワーク要件Cephを実行する予定のネットワーク環境は、2つ以上のネットワークインタフェースボンディングした

セットにし、このセットを、VLANを使用してパブリック部分と信頼する内部部分に論理的に分割するの

が理想です。最大の帯域幅と災害耐性を提供するため、可能であればボンディングモードは802.3ad

にすることをお勧めします。

パブリックVLANは顧客にサービスを提供する役目を果たすのに対し、内部部分は認証されたCeph

ネットワーク通信を提供します。この主な理由は、Cephはいったん秘密鍵が用意されれば認証と攻撃

に対する保護を提供しますが、その鍵の設定に使用されるメッセージはオープンに転送される場合が

あり、脆弱であるためです。

ヒント: DHCP経由で設定されたノードストレージノードがDHCP経由で設定されている場合、さまざまCephデーモンが起動する前に

ネットワークを正しく設定するのにデフォルトのタイムアウトでは十分でないことがあります。こ

の場合、Ceph MONとOSDは正しく起動しません( systemctl status ceph\*を実行する

と、「unable to bind (バインドできません)」というエラーが発生します)。この問題を避けるた

め、Storage Cluster内の各ノードでDHCPクライアントのタイムアウトを30秒以上に増やすこ

とをお勧めします。このためには、各ノードで以下の設定を変更します。

/etc/sysconfig/network/dhcpで、以下を設定します。

DHCLIENT_WAIT_AT_BOOT="30"

/etc/sysconfig/network/configで、以下を設定します。

WAIT_FOR_INTERFACES="60"

2.9.1 実行中のクラスタへのプライベートネットワークの追加Cephの展開中にクラスタネットワークを指定しない場合、単一のパブリックネットワーク環境と想定さ

れます。Cephはパブリックネットワークで問題なく動作しますが、2つ目のプライベートクラスタネット

ワークを設定すると、パフォーマンスとセキュリティが向上します。2つのネットワークをサポートするに

は、各Cephノードに少なくとも2つのネットワークカードが必要です。

各Cephノードに以下の変更を適用する必要があります。これらの変更は、小規模なクラスタの場合は

比較的短時間で済みますが、数百または数千のノードで構成されるクラスタの場合は非常に時間がか

かる可能性があります。

1. 各クラスタノードでCeph関連サービスを停止します。

16 ネットワーク要件 SES 6

/etc/ceph/ceph.confに行を追加してクラスタネットワークを定義します。次に例を示します。

cluster network = 10.0.0.0/24

特に静的IPアドレスを割り当てたり、 cluster network設定を上書きしたりする必要がある場

合は、オプションの cluster addrで設定できます。

2. プライベートクラスタネットワークがOSレベルで想定どおりに動作していることを確認します。

3. 各クラスタノードでCeph関連サービスを起動します。

root # systemctl start ceph.target

2.9.2 異なるサブネット上のモニタノードモニタノードが複数のサブネット上に存在する場合(たとえば、別の部屋に配置されていたり、別のス

イッチによってサービスを提供されていたりする場合)、適切に ceph.confファイルを調整する必要が

あります。たとえば、ノードにIPアドレス192.168.123.12、1.2.3.4、および242.12.33.12が設定されて

いる場合、 globalセクションに次の行を追加します。

[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]

さらに、モニタごとにパブリックアドレスまたはネットワークを指定する必要がある場合は、各モニタに対

して [mon.X]セクションを追加する必要があります。

[mon.MON1]public network = 192.168.123.0/24



2.10 命名の制限一般的に、Cephは、設定ファイル、プール名、ユーザ名などでASCII以外の文字をサポートしませ

ん。Cephクラスタを設定する場合、すべてのCephオブジェクト名/設定名で単純な英数字の文字(A

〜Z、a〜z、0〜9)と、最小限の句読点(「.」「-」「_」)のみを使用することをお勧めします。

17 異なるサブネット上のモニタノード SES 6

2.11 OSDとモニタでの1台のサーバの共有テスト環境ではCeph OSDとモニタを同じサーバで実行することは技術的に可能ですが、運用では

モニタノードごとに別個のサーバを用意することを強くお勧めします。その主な理由はパフォーマンス

です。クラスタのOSDが増えるほど、モニタノードが実行しなければならないI/O操作が増えます。さら

に、1台のサーバをモニタノードとOSDで共有する場合、OSDのI/O操作がモニタノードにとって制限

要因になります。

考慮すべきもう1つの点は、サーバ上のOSD、モニタノード、およびオペレーティングシステムでディスク

を共有するかどうかです。答えは単純です。可能であれば、OSDには別個の専用ディスクを使用し、モ

ニタノードには別個の専用サーバを使用します。

CephはディレクトリベースのOSDをサポートしますが、OSDには、常にオペレーティングシステムの

ディスクではなく専用ディスクを使用する必要があります。

ヒントOSDとモニタノードを「本当に」同じサーバで実行する必要がある場合は、モニタを別個のディ

スクで実行し、そのディスクを /var/lib/ceph/monディレクトリにマウントすることで、少しでも

パフォーマンスを向上させます。

2.12 運用クラスタの推奨設定

7つのオブジェクトストレージノード

1つのノードが最大で合計ストレージの15%を超えないこと

10Gb Ethernet (複数のスイッチにボンディングされた4つの物理ネットワーク)

Storage Clusterあたり56以上のOSD

各OSDストレージノードに対してRAID 1のOSディスク

ジャーナル用のSSD (SSDジャーナルとOSDの比率は6:1)

各オブジェクトストレージノードに対して、OSDの未加工容量1TBあたり1.5GBのRAM

各オブジェクトストレージノードに対してOSDあたり2GHz

専用の物理インフラストラクチャノード

18 OSDとモニタでの1台のサーバの共有 SES 6

3つのCeph Monitorノード: 4GBのRAM、4コアプロセッサ、ディスク用のRAID 1 SSD

1つのSES管理ノード: 4GBのRAM、4コアプロセッサ、ディスク用のRAID 1 SSD

ゲートウェイまたはMetadata Serverノードの冗長な物理展開:

Object Gatewayノード: 32GBのRAM、8コアプロセッサ、ディスク用のRAID 1

SSD

iSCSI Gatewayノード: 16GBのRAM、4コアプロセッサ、ディスク用のRAID 1

SSD

Metadata Serverノード(アクティブ x 1/ホットスタンバイ x 1): 32GBのRAM、8コ

アプロセッサ、ディスク用のRAID 1 SSD

2.13 SUSE Enterprise Storage 6とその他のSUSE製品このセクションには、SUSE Enterprise Storage 6と他のSUSE製品との統合に関する重要な情報が

記載されています。

2.13.1 SUSE Manager

SUSE ManagerとSUSE Enterprise Storageは統合されていません。そのため、現在のところSUSE

ManagerでSUSE Enterprise Storage Clusterを管理することはできません。

19 SUSE Enterprise Storage 6とその他のSUSE製品 SES 6

3 管理ノードのHAセットアップ

「管理ノード」は、Salt Masterサービスが動作するCephクラスタノードです。管理ノードは、Salt

Minionサービスに対してクエリと命令を行うことで他のクラスタノードを管理するので、Cephクラスタ

の中心となる場所です。管理ノードには通常、ほかのサービスも含まれます。たとえば、Cephダッシュ

ボードWeb UIと、「Prometheus」監視ツールキットを利用する「Grafana」ダッシュボードなどです。

管理ノードに障害が発生した場合、通常は、動作する新しいハードウェアをノードに提供し、最新のバッ

クアップから完全なクラスタ設定スタックを復元する必要があります。この方法では時間がかかり、クラ

スタの停止も発生します。

管理ノードの障害によってCephクラスタのパフォーマンスにダウンタイムが発生するのを防止するた

め、Ceph管理ノードにはHA (高可用性)クラスタを利用することをお勧めします。

3.1 管理ノードのHAクラスタの概要HAクラスタは、一方のクラスタノードで障害が発生した場合に、もう一方のノードがその役割(仮想化さ

れた管理ノードを含む)を自動的に引き継ぐという考えです。こうすることで、管理ノードに障害が発生し

たことを他のCephクラスタノードが認識することはありません。

管理ノード用の最小限のHAソリューションには、次のハードウェアが必要です。

High Availability ExtensionをインストールしたSUSE Linux Enterpriseを実行し、管理ノー

ドを仮想化できるベアメタルサーバ2台。

2つ以上の冗長ネットワーク通信パス。たとえば、ネットワークデバイスボンディングを使用します。

管理ノード仮想マシンのディスクイメージをホストするための共有ストレージ。この共有ストレージ

は両方のサーバからアクセス可能である必要があります。たとえば、NFSエクスポート、Samba共

有、iSCSIターゲットなどを使用できます。

クラスタの要件の詳細については、https://www.suse.com/documentation/sle-ha-15/

book_sleha_quickstarts/data/sec_ha_inst_quick_req.html を参照してください。

20 管理ノードのHAクラスタの概要 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html

図 3.1: 管理ノードの2ノードHAクラスタ

3.2 管理ノードによるHAクラスタの構築次の手順は、管理ノードを仮想化するためのHAクラスタを構築する手順の中で最も重要なものをまと

めたものです。詳細については、記載のリンクを参照してください。

1. 共有ストレージを使用する基本的な2ノードHAクラスタを設定します。https://

www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

art_sleha_install_quick.html を参照してください。

2. 両方のクラスタノードに、KVMハイパーバイザを実行するために必要なすべてのパッケージ

と libvirtツールキットをインストールします。https://www.suse.com/documentation/

sles-15/book_virt/data/sec_vt_installation_kvm.html を参照してください。

3. 1つ目のクラスタノードで、 libvirtを利用する新しいKVM VM (仮想マシン)を作

成します。https://www.suse.com/documentation/sles-15/book_virt/data/

sec_libvirt_inst_vmm.html を参照してください。事前設定済みの共有ストレージを使用し

て、VMのディスクイメージを保存します。

4. VMのセットアップが完了したら、その設定を共有ストレージ上のXMLファイルにエクスポートし

ます。使用する構文は次のとおりです。

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

21 管理ノードによるHAクラスタの構築 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html



https://www.suse.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_libvirt_inst_vmm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_libvirt_inst_vmm.html

5. 管理ノードVMのリソースを作成します。HAリソースの作成に関する全般的な情報につい

ては、https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/

cha_conf_hawk2.html を参照してください。KVM仮想マシンのリソースの作成に関する詳

細情報については、http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent

%29 を参照してください。

6. 新しく作成したVMゲストで、管理ノードと、そこで必要な追加サービスを展開します。5.3項「ク

ラスタの展開」の関連手順に従います。同時に、非HAクラスタサーバに残りのCephクラスタノー

ドを展開します。

22 管理ノードによるHAクラスタの構築 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_conf_hawk2.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_conf_hawk2.html

http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29

http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29

4 ユーザの特権とコマンドプロンプト

Cephクラスタ管理者は、特定のコマンドを実行して、クラスタの動作を設定および調整します。必要に

なるコマンドには、次のように複数のタイプがあります。

4.1 Salt/DeepSea関連のコマンドこれらのコマンドは、Cephクラスタを展開またはアップグレードしたり、クラスタノードの一部(または全

部)で同時にコマンドを実行したり、クラスタノードを追加または削除したりする際に役立ちます。最も頻

繁に使用されるコマンドは、 salt 、 salt-run 、および deepseaです。Salt Masterノードでは、Saltコ

マンドは rootとして実行する必要があります(5.2項「DeepSeaの概要」を参照)。これらのコマンドは、

次のプロンプトで紹介されています。

root@master #

次に例を示します。

root@master # salt '*.example.net' test.ping

4.2 Ceph関連のコマンドこれらは、クラスタとそのゲートウェイのすべての側面をコマンドラインで設定および微調整するための

下位レベルのコマンドです。たとえば、 ceph 、 rbd 、 radosgw-admin 、 crushtoolなどです。

Ceph関連のコマンドを実行するには、Cephキーの読み込みアクセス権が必要です。このキーの

機能により、Ceph環境内におけるユーザの特権が定義されます。1つのオプションは、 rootと

して(または sudoを使用して)Cephコマンドを実行し、制限のないデフォルトのキーリング

「ceph.client.admin.key」を使用します。

より安全な推奨オプションは、各管理者ユーザに対してより制限の厳しい個別のキーを作成し、その

キーを、各ユーザが読み込むことができるディレクトリに保存することです。次に例を示します。

~/.ceph/ceph.client.USERNAME.keyring

ヒント: Cephキーのパスカスタムの管理者ユーザとキーリングを使用するには、 cephコマンドを実行するたびに、 -n

client.USER_NAMEオプションと --keyring PATH/TO/KEYRINGオプションを使用して、ユー

ザ名とプールのパスを指定する必要があります。

23 Salt/DeepSea関連のコマンド SES 6

これを回避するには、これらのオプションを CEPH_ARGS 変数(個々のユーザの ~/.bashrcファ

イル。

Ceph関連のコマンドは任意のクラスタノードで実行できますが、管理ノードで実行することをお勧めし

ます。このドキュメントでは、 cephadmユーザを使用してコマンドを実行するので、コマンドは次のプロン

プトで紹介されています。

cephadm@adm >


cephadm@adm > ceph auth list

ヒント: 特定のノード用のコマンドクラスタノードに対して特定の役割でコマンドを実行するようドキュメントで指示されている場合

は、プロンプトによって示されます。次に例を示します。

cephadm@mon >

4.3 一般的なLinuxコマンドmount 、 cat 、 opensslなど、CephまたはDeepSeaに関係しないLinuxコマンドは、関連するコマンド

で必要な特権に応じて、 cephadm@adm > プロンプトまたは root # プロンプトのいずれかで紹介

されています。

4.4 追加情報Cephのキー管理の詳細については、『管理ガイド』、第8章「cephxを使用した認証」、8.2項「キー管

理」を参照してください。

24 一般的なLinuxコマンド SES 6

II クラスタの展開とアップグレード

5 DeepSea/Saltを使用した展開 26

6 古いリリースからのアップグレード 58

7 デフォルト設定のカスタマイズ 85

5 DeepSea/Saltを使用した展開

SaltとDeepSeaは、サーバインフラストラクチャの展開と管理に役立つコンポーネントの「スタック」で

す。拡張性が非常に高く高速で、比較的簡単に運用を開始できます。Saltを使用してクラスタの展開を

始める前に、以下の考慮事項をお読みください。

「Salt Minion」は、Salt Masterと呼ばれる専用のノードによって制御されるノードです。Salt

Minionは、Ceph OSD、Ceph Monitor、Ceph Manager、Object Gateway、iSCSI

Gateway、NFS Ganeshaなどの役割を持ちます。

Salt Masterは専用のSalt Minionを実行します。これは特権タスク(キーの作成や権限付与、ミ

ニオンへのキーのコピーなど)を実行するために必要で、その結果、リモートミニオンは特権タスク

を実行しなくても済みます。

ヒント: 1つのサーバで複数の役割を共有各役割を別個のノードに展開すると、Cephクラスタで最適なパフォーマンスを実現でき

ます。しかし、実際の展開では、1つのノードを複数の役割のために共有しなければならな

い場合があります。パフォーマンスやアップグレード手順で問題が起きないようにするた

め、Ceph OSD、Metadata Server、またはCeph Monitorの役割は管理ノードに展開し

ないでください。

Salt Minionは、ネットワークでSalt Masterのホスト名を正しく解決する必要があります。Salt

Minionは、デフォルトでは saltというホスト名を検索しますが、ネットワーク経由でアクセス可

能なほかのホスト名を /etc/salt/minionファイルで指定できます。5.3項「クラスタの展開」を

参照してください。

5.1 リリースノートの確認リリースノートには、旧リリースのSUSE Enterprise Storageからの変更点に関する追加情報が記載

されています。リリースノートを参照して以下を確認します。

使用しているハードウェアに特別な配慮が必要かどうか

使用しているソフトウェアパッケージに大幅な変更があるかどうか

インストールのために特別な予防措置が必要かどうか

リリースノートには、マニュアルに記載できなかった情報が記載されています。また、既知の問題に関す

る注意も記載されています。

26 リリースノートの確認 SES 6

パッケージ release-notes-sesをインストールすると、リリースノートは、ローカルではディレクトリ /

usr/share/doc/release-notesに、オンラインではhttps://www.suse.com/releasenotes/ に

あります。

5.2 DeepSeaの概要DeepSeaの目的は、管理者の時間を節約し、Cephクラスタの複雑な操作を確実に実行できるように

することです。

Cephは、設定を細かく変更可能なソフトウェアソリューションです。Cephはシステム管理者の自由度

と対応能力の両方を向上させます。

デモンストレーションにはCephの最小セットアップで十分ですが、これでは大量のノードがある場合に

発揮されるCephの興味深い機能はわかりません。

DeepSeaは、アドレスやデバイス名など、個々のサーバのデータを収集、保存します。Cephのような分

散ストレージシステムでは、収集および保存すべきこのような項目が何百個も存在する可能性がありま

す。手動で情報を収集して設定管理ツールにデータを入力するのは、たいへんな労力が必要なだけで

なく、ミスも起きがちです。

サーバの準備、設定の収集、およびCephの展開に必要な手順はほぼ同じです。ただし、これは別個の

機能の管理には対応していません。日々の運用では、特定の機能に簡単にハードウェアを追加したり、

ハードウェアを問題なく削除したりできる必要があります。

DeepSeaは、管理者の決定事項を1つのファイルに統合するというストラテジーによって、こうした現実

の課題に対応します。クラスタの割り当て、役割の割り当て、プロファイルの割り当てなどが決定事項に

含まれます。DeepSeaは各タスクセットを収集してシンプルな目標にまとめます。それぞれの目標は「ス

テージ」です。

DEEPSEAのステージの説明

「ステージ 0」 - 「準備」 - このステージ中に、必要な更新がすべて適用されます。システムが再起

動することがあります。

重要: 管理ノード再起動後のステージ0の再実行ステージ0の間に、管理ノードは新しいカーネルバージョンをロードするために再起動する

ので、もう一度ステージ0を実行する必要があります。そうしないと、ミニオンがターゲットに

設定されません。

「ステージ1」 - 「ディスカバリ」 - ここでは、クラスタ内のすべてのハードウェアが検出され、Ceph

の設定に必要な情報が収集されます。設定の詳細については、5.5項「設定とカスタマイズ」を参

照してください。

27 DeepSeaの概要 SES 6

https://www.suse.com/releasenotes/

「ステージ2」 - 「設定」 - 設定データを特定のフォーマットで準備する必要があります。

「ステージ3」 - 「展開」 - 必須のCephサービスが含まれる基本的なCephクラスタを作成します。

リストについては、1.2.3項「Cephのノードとデーモン」を参照してください。

「ステージ4」 - 「サービス」 - このステージでは、iSCSI、Object Gateway、CephFSなど、Ceph

の追加機能をインストールできます。各機能はオプションです。

「ステージ5」 - 削除ステージ。このステージは必須ではなく、通常、初期セットアップ時には必要

ありません。このステージでは、ミニオンの役割のほかにクラスタ設定も削除されます。このステー

ジは、クラスタからストレージノードを削除する必要がある場合に実行する必要があります。詳細

については、『管理ガイド』、第2章「Saltクラスタの管理」、2.3項「クラスタノードの削除と再インス

トール」を参照してください。

5.2.1 組織と重要な場所

Saltには、マスタノードで使用される標準の場所と命名規則がいくつか設定されています。

/srv/pillar

このディレクトリには、クラスタミニオンの設定データが保存されます。「Pillar」は、すべてのクラス

タミニオンにグローバル設定値を提供するためのインタフェースです。

/srv/salt/

このディレクトリには、Saltの状態ファイル(「sls」ファイルとも呼びます)が保存されます。状態ファ

イルは、クラスタのあるべき状態を特定のフォーマットで記述したものです。

/srv/module/runners

このディレクトリには、ランナと呼ばれるPythonスクリプトが保存されます。ランナはマスタノード

で実行されます。

/srv/salt/_modules

このディレクトリには、モジュールと呼ばれるPythonスクリプトが保存されます。モジュールはクラ

スタ内のすべてのミニオンに適用されます。

/srv/pillar/ceph

このディレクトリはDeepSeaによって使用されます。収集された設定データはここに保存されま

す。

/srv/salt/ceph

28 組織と重要な場所 SES 6

DeepSeaによって使用されるディレクトリ。さまざまなフォーマットのslsファイルが保存されます

が、各サブディレクトリにslsファイルが含まれます。各サブディレクトリには1種類のslsファイルの

みが含まれます。たとえば、 /srv/salt/ceph/stageには、 salt-run state.orchestrateに

よって実行されるオーケストレーションファイルが含まれます。

5.2.2 ミニオンのターゲット設定

DeepSeaのコマンドはSaltインフラストラクチャ経由で実行されます。 saltコマンドを使用する場合、

コマンドの対象にするSalt Minionのセットを指定する必要があります。ここでは、そのようなミニオンの

セットを saltコマンドの「ターゲット」と呼びます。以降のセクションでは、ミニオンのターゲットを設定す

るために使用できる方法について説明します。

5.2.2.1 ミニオン名の一致

1つのミニオンまたは複数のミニオンのグループを名前で照合してターゲットに設定できます。通常、ミ

ニオンの名前は、ミニオンが実行されているノードの短いホスト名です。これは、Saltの一般的なター

ゲット設定方法で、DeepSeaには関係ありません。グロブ、正規表現、またはリストを使用して、ミニオン

名の範囲を制限できます。一般的な構文は次のとおりです。

root@master # salt target example.module

ヒント: Cephのみのクラスタユーザの環境内のすべてのSalt Minionがそのユーザ自身のCephクラスタに属する場合

は、 targetを「 * 」に置き換えて、「すべて」の登録済みミニオンを含めて問題ありません。

example.netドメイン内のすべてのミニオンに一致します(ミニオン名がその「完全な」ホスト名と同じ

であると想定しています)。

root@master # salt '*.example.net' test.ping

「web1」〜「web5」のミニオンに一致します。

root@master # salt 'web[1-5]' test.ping

正規表現を使用して、「web1-prod」と「web1-devel」の両方のミニオンに一致します。

root@master # salt -E 'web1-(prod|devel)' test.ping

29 ミニオンのターゲット設定 SES 6

ミニオンの単純なリストに一致します。

root@master # salt -L 'web1,web2,web3' test.ping

クラスタ内のすべてのミニオンに一致します。

root@master # salt '*' test.ping

5.2.2.2 DeepSeaグレインを使用したターゲット設定

Saltによって管理される異種環境において、SUSE Enterprise Storage 6が他のクラスタソリューショ

ンと共にノードのサブセットに展開されている場合、DeepSeaステージ0を実行する前に「deepsea」グ

レインを適用して、関連するミニオンにマークを付ける必要があります。これにより、ミニオン名での一致

が難しい環境で、DeepSeaミニオンを簡単にターゲットに設定できます。

「deepsea」グレインをミニオンのグループに適用するには、次のコマンドを実行します。

root@master # salt target grains.append deepsea default

「deepsea」グレインをミニオンのグループから削除するには、次のコマンドを実行します。

root@master # salt target grains.delval deepsea destructive=True

「deepsea」グレインを関連するミニオンに適用した後、次のようにミニオンをターゲットに設定できま

す。

root@master # salt -G 'deepsea:*' test.ping

次のコマンドも同等の処理を行います。

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 deepsea_minionsオプションの設定

DeepSeaの展開では、 deepsea_minionsオプションのターゲットを設定する必要がありま

す。DeepSeaは、このオプションを使用して、ステージの実行中にミニオンに命令します(詳細について

は、DeepSeaのステージの説明を参照してください)。

deepsea_minionsオプションを設定または変更するには、Salt Masterで /srv/pillar/ceph/

deepsea_minions.slsファイルを編集し、次の行を追加または置換します。

deepsea_minions: target

30 ミニオンのターゲット設定 SES 6

ヒント: deepsea_minionsのターゲットdeepsea_minionsオプションの targetとして、「ミニオン名の一致」および「DeepSeaグレイ

ンを使用したターゲット設定」の両方のターゲット設定方法を使用できます。

クラスタ内のすべてのSalt Minionに一致します。

deepsea_minions: '*'

「deepsea」グレインを使用してすべてのミニオンに一致します。

deepsea_minions: 'G@deepsea:*'

5.2.2.4 その他の情報

Saltインフラストラクチャを使用して、より高度な方法でミニオンをターゲットに設定できます。

「deepsea-minions」のマニュアルページでは、DeepSeaのターゲット設定が詳しく説明されています

( man 7 deepsea_minions )。

5.3 クラスタの展開クラスタの展開プロセスには複数のフェーズがあります。まず、Saltを設定してクラスタのすべてのノード

を準備してから、Cephを展開および設定する必要があります。

ヒント: OSDプロファイルを定義せずにモニタノードを展開5.5.1.2項「役割割り当て」で説明されている、OSDのストレージ役割の定義をスキップして、最

初にCeph Monitorノードを展開する必要がある場合、 DEV_ENV変数を設定することにより実

行できます。

これにより、 role-storage/ディレクトリが存在しなくてもモニターを展開できるほか、ストレー

ジの役割、モニターの役割、およびマネージャの役割が少なくとも「1つ」あればCephクラスタを

展開できます。

この環境変数を設定するには、 /srv/pillar/ceph/stack/global.ymlファイルで設定して

グローバルに有効にするか、現在のシェルセッションに対してのみ設定します。

root@master # export DEV_ENV=true

たとえば、次の内容で /srv/pillar/ceph/stack/global.ymlを作成できます。

31 クラスタの展開 SES 6

DEV_ENV: True

次の手順では、クラスタの準備について詳しく説明します。

1. クラスタの各ノードにSUSE Linux Enterprise Server 15 SP1とSUSE Enterprise Storage

6拡張機能をインストールして登録します。

2. 既存のソフトウェアリポジトリを一覧にして、適切な製品がインストールおよび登録されていること

を確認します。 zypper lr -Eを実行して、出力を次のリストと比較します。

SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates

3. ネットワークを設定します。各ノードでDNS名が適切に解決されるようにする設定も含まれま

す。Salt MasterとすべてのSalt Minionは、お互いをホスト名で解決する必要があります。

ネットワークの設定の詳細については、https://www.suse.com/documentation/sles-15/

book_sle_admin/data/sec_network_yast.html を参照してください。DNSサーバの設定

の詳細については、https://www.suse.com/documentation/sles-15/book_sle_admin/

data/cha_dns.html を参照してください。

4. 1つ以上のタイムサーバ/プールを選択し、ローカル時刻をそれらと同期します。システムを起動

するたびに時刻同期サービスが有効になることを確認します。時刻同期を設定するには、 yast

ntp-clientコマンドを使用できます。このコマンドは、 yast2-ntp-client パッケージにありま

す。

ヒント仮想マシンは信頼できるNTPソースではありません。

NTPの設定の詳細については、https://www.suse.com/documentation/sles-15/

book_sle_admin/data/sec_ntp_yast.html を参照してください。

5. Salt Masterノードに salt-masterパッケージと salt-minionパッケージをインストールしま

す。


https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html

root@master # zypper in salt-master salt-minion

salt-masterサービスが有効になっていて起動していることを確認します。必要であれば、サー

ビスを有効にして起動します。

root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service

6. ファイアウォールを使用する場合は、Salt Masterノードのポート4505と4506がすべてのSalt

Minionノードに対して開いていることを確認します。これらのポートが閉じている場合は、 yast2

firewallコマンドを使用してポートを開き、［SaltStack］サービスを許可できます。

警告: ファイアウォールがアクティブな場合、DeepSeaのステージが失敗するファイアウォールがアクティブな場合(かつ設定されている場合)、DeepSeaの展開ステー

ジが失敗します。ステージを正しく実行するには、次のコマンドを実行してファイアウォー

ルをオフにします。

root # systemctl stop firewalld.service

または、 /srv/pillar/ceph/stack/global.ymlの FAIL_ON_WARNINGオプションを

「False」に設定します。

FAIL_ON_WARNING: False

7. パッケージ salt-minionをすべてのミニオンノードにインストールします。

root@minion > zypper in salt-minion

各ノードの「完全修飾ドメイン名」を他のすべてのノードがパブリックネットワークのIPアドレスに

解決できることを確認します。

8. すべてのミニオン(マスタミニオンを含む)を、マスタに接続するように設定します。ホスト

名 saltでSalt Masterに接続できない場合は、ファイル /etc/salt/minionを編集するか、次

の内容で新しいファイル /etc/salt/minion.d/master.confを作成します。

master: host_name_of_salt_master

上で説明した設定ファイルを変更した場合は、すべてのSalt MinionのSaltサービスを再起動し

ます。


root@minion > systemctl restart salt-minion.service

9. すべてのノードで salt-minionサービスが有効になっていて起動していることを確認します。必

要であれば、次のコマンドを使用して有効にして起動します。

root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service

10. 各Salt Minionの指紋を確認して、指紋が一致する場合、Salt Master上のすべてのSaltキーを

受諾します。

注記Salt Minionの指紋が空に戻る場合は、Salt MinionがSalt Masterの設定を持ってい

て、Salt Masterと通信できることを確認します。

各ミニオンの指紋を表示します。

root@master # salt-call --local key.fingerlocal:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

すべてのSalt Minionの指紋を収集した後、Salt Master上の、受諾されていない全ミニオン

キーの指紋を一覧にします。

root@master # salt-key -F[...]Unaccepted Keys:minion1:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

ミニオンの指紋が一致する場合は、それらを受諾します。

root@master # salt-key --accept-all

11. キーが受諾されたことを確認します。

root@master # salt-key --list-all

12. SUSE Enterprise Storage 6を展開する前に、すべてのディスクを手動で消去します。必ず「X」

を正しいディスク文字に置き換えてください。

a. 指定したディスクを使用しているすべてのプロセスを停止します。


b. ディスクのパーティションがマウントされているかどうかを確認し、必要に応じてアンマウン

トします。

c. ディスクがLVMによって管理されている場合は、LVMインフラストラクチャ全体を無効に

して削除します。詳細については、https://www.suse.com/documentation/sles-15/

book_storage/data/cha_lvm.html を参照してください。

d. ディスクがMD RAIDの一部である場合は、RAIDを無効化します。詳細について

は、https://www.suse.com/documentation/sles-15/book_storage/data/

part_software_raid.html を参照してください。

e. ヒント: サーバの再起動次の手順の実行中に「partition in use (パーティションが使用中です)」や

「kernel can not be updated with the new partition table (カーネルを新し

いパーティションテーブルで更新できません)」などのエラーメッセージが表示され

る場合、サーバを再起動してください。

各パーティションの先頭を消去します( rootとして)。

for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone

f. ドライブの先頭を消去します。

root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct

g. ドライブの最後を消去します。

root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct

h. 次のコマンドを使用して、ドライブが空(GPT構造なし)であることを確認します。

root # parted -s /dev/sdX print free

プロンプトまたは

root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C


https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html

https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html

https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html

https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html

13. オプションで、 deepsea パッケージがインストールされる前に、クラスタのネットワーク設定を事

前設定する必要がある場合は、 /srv/pillar/ceph/stack/ceph/cluster.ymlを手動で作

成して、 cluster_network:オプションと public_network:オプションを設定します。このファ

イルは、 deepseaをインストールした後も上書きされないことに注意してください。

ヒント: IPv6の有効化IPv6ネットワークのアドレス指定を有効にする必要がある場合は、7.2.1項「Cephクラス

タ展開のためのIPv6の有効化」を参照してください。

14. DeepSeaをSalt Masterノードにインストールします。

root@master # zypper in deepsea

15. master_minionパラメータの値は、Salt Master上の /etc/salt/minion_idファイルから

動的に導出されます。検出された値を上書きする必要がある場合は、ファイル /srv/pillar/

ceph/stack/global.ymlを編集して、関連する値を設定します。

master_minion: MASTER_MINION_NAME

ほかのホスト名でもSaltマスタにアクセスできる場合は、 salt-key -Lコマンドで返されるSalt

Minion名をストレージクラスタに対して使用します。「ses」ドメインでSalt Masterにデフォルト

のホスト名(「salt」)を使用していた場合、次のようなファイルになります。

master_minion: salt.ses

続いてCephを展開して設定します。別途明記されていない限り、すべての手順が必須です。

注記: Saltコマンドの規則salt-run state.orchは2つの方法で実行できます。1つは「stage. STAGE_NUMBER 」を使用

する方法で、もう1つはステージの名前を使用する方法です。どちらの表記でも効果は同じで、

どちらのコマンドを使用するかは完全に好みの問題です。

手順 5.1: 展開ステージの実行

1. Cephクラスタに属するSalt Minionが /srv/pillar/ceph/

deepsea_minions.slsの deepsea_minionsオプションで正しくターゲットに設定されている

ことを確認します。詳細については、「5.2.2.3項「deepsea_minionsオプションの設定」」を参照

してください。


2. デフォルトでは、DeepSeaは、Ceph Monitor、Ceph Manager、およびCeph OSDのノード上

でアクティブな調整済みプロファイルを使用してCephクラスタを展開します。場合によっては、

調整済みプロファイルを使用せずに展開しなければならないことがあります。これを実行するに

は、DeepSeaステージを実行する前に、 /srv/pillar/ceph/stack/global.ymlに次の行を

入力します。

alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off

3. オプション: /var/lib/ceph/のBtrfsサブボリュームを作成します。この手順は、DeepSeaス

テージ0の前に実行する必要があります。既存のディレクトリを移行する方法、または詳細につ

いては、『管理ガイド』、第25章「ヒント」、25.6項「Ceph Monitorノード上の/var/lib/cephの

Btrfsサブボリューム」を参照してください。

Salt Minionのそれぞれに次のコマンドを適用します。

root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

注記Ceph.subvolumeコマンドは、 /var/lib/cephを @/var/lib/ceph Btrfsサブボリュー

ムとして作成します。

新しいサブボリュームがマウントされ、 /etc/fstabが更新されます。

4. クラスタを準備します。詳細については、DeepSeaのステージの説明を参照してください。

root@master # salt-run state.orch ceph.stage.0

または

root@master # salt-run state.orch ceph.stage.prep

注記: DeepSea CLIを使用したステージの実行または監視DeepSea CLIを使用して、ステージの実行進行状況をリアルタイムで把握できます。そ

のためには、DeepSea CLIをモニタリングモードで実行するか、DeepSea CLIを通じて

ステージを直接実行します。詳細については、5.4項「DeepSea CLI」を参照してくださ

い。


5. ディスカバリステージでは、すべてのミニオンからデータを収集して、ディレクトリ /srv/pillar/

ceph/proposalsに保存される設定フラグメントを作成します。データはYAMLフォーマットで

*.slsファイルまたは*.ymlファイルに保存されます。

次のコマンドを実行して、ディスカバリステージをトリガします。


または

root@master # salt-run state.orch ceph.stage.discovery

6. 前のコマンドが正常に完了した後、 /srv/pillar/ceph/proposalsに policy.cfgファイルを

作成します。詳細については、5.5.1項「policy.cfgファイル」を参照してください。

ヒントクラスタのネットワーク設定を変更する必要がある場合は、 /srv/pillar/ceph/stack/

ceph/cluster.ymlを編集して、 cluster_network:および public_network:で始ま

る各行を調整します。

7. 設定ステージにより、 policy.cfgファイルが解析され、含まれるファイルが最終的な形態に

マージされます。クラスタと役割に関連する内容は /srv/pillar/ceph/clusterに保存さ

れ、Ceph固有の内容は /srv/pillar/ceph/stack/defaultに配置されます。

次のコマンドを実行して、設定ステージをトリガします。


または

root@master # salt-run state.orch ceph.stage.configure

この設定手順には数秒かかる場合があります。コマンドが完了した後、指定したミニオンのPillar

データを表示できます(たとえば、 ceph_minion1 、 ceph_minion2という名前のミニオンなど)。

このためには、次のコマンドを実行します。

root@master # salt 'ceph_minion*' pillar.items

ヒント: OSDのレイアウトの変更OSDのデフォルトのレイアウトを変更し、ドライブグループの設定を変更する場合

は、5.5.2項「DriveGroups」で説明されている手順に従います。


注記: デフォルト値の上書きコマンドが完了したら、すぐにデフォルト設定を参照して、ニーズに合わせて変更できま

す。詳細については、第7章「デフォルト設定のカスタマイズ」を参照してください。

8. これで展開ステージを実行できます。このステージでは、Pillarが検証され、Ceph Monitorおよ

びCeph OSDデーモンが開始されます。


または

root@master # salt-run state.orch ceph.stage.deploy

このコマンドには数分かかる場合があります。コマンドが失敗した場合は、問題を修正して前のス

テージをもう一度実行する必要があります。コマンドが成功したら、次のコマンドを実行して状態を

確認します。

cephadm@adm > ceph -s

9. Cephクラスタ展開の最後の手順は、「サービス」ステージです。ここでは、現在サポートされてい

るサービス(iSCSI Gateway、CephFS、Object Gateway、およびNFS Ganesha)のインスタ

ンスを生成します。このステージで、必要なプール、権限付与キーリング、および起動サービスが

作成されます。ステージを開始するには、次のコマンドを実行します。


または

root@master # salt-run state.orch ceph.stage.services

セットアップによっては、このコマンドの実行には数分かかる場合があります。

10. 続行する前に、Cephテレメトリモジュールを有効にすることを強くお勧めします。情報および手順

の詳細については、『管理ガイド』、第10章「Ceph Managerモジュール」、10.2項「テレメトリモ

ジュール」を参照してください。


5.4 DeepSea CLIDeepSeaは、ユーザがステージを監視または実行しながら、実行進行状況をリアルタイムで可視化で

きるCLI (コマンドラインインタフェース)ツールも備えています。パッケージ deepsea-cli がインス

トールされていることを確認してから、 deepsea実行可能ファイルを実行します。

ステージの実行進行状況を可視化するため、次の2つのモードがサポートされています。

DEEPSEA CLIのモード

モニタリングモード: 別のターミナルセッションで発行された salt-runコマンドによってトリガさ

れたDeepSeaステージの実行進行状況を可視化します。

スタンドアロンモード: DeepSeaステージを実行すると同時に、その構成要素の実行中にリアル

タイムで各手順を可視化します。

重要: DeepSea CLIコマンドDeepSea CLIコマンドは、Salt Masterノードで、 root特権でのみ実行できます。

5.4.1 DeepSea CLI: モニタモード

進行状況モニタは、他のターミナルセッションで salt-run state.orchコマンドを使用して実行され

ているステージで何が実行されているかをリアルタイムで詳しく可視化します。

ヒント: 新しいターミナルセッションでのモニターの起動salt-run state.orchを実行する「前に」、ステージの実行開始を検出できるようモニターを

新しいターミナルウィンドウで起動しておく必要があります。

salt-run state.orchコマンドの発行後にモニタを起動した場合、実行進行状況は表示されませ

ん。

次のコマンドを実行して、モニタモードを開始できます。

root@master # deepsea monitor

deepsea monitorコマンドで利用可能なコマンドラインオプションの詳細については、次のマニュア

ルページを参照してください。

root@master # man deepsea-monitor

40 DeepSea CLI SES 6

5.4.2 DeepSea CLI: スタンドアロンモード

スタンドアロンモードでは、DeepSea CLIを使用してDeepSeaステージを実行し、その実行をリアルタ

イムで表示できます。

DeepSea CLIからDeepSeaステージを実行するコマンドは次の形式です。

root@master # deepsea stage run stage-name

ここで、 stage-nameは、Saltオーケストレーション状態ファイルが参照される方法に対応します。たと

えば、ステージ「deploy」は、 /srv/salt/ceph/stage/deployにあるディレクトリに対応しており、

「ceph.stage.deploy」として参照されます。

このコマンドは、DeepSeaステージ(またはDeepSeaオーケストレーション状態ファイル)を実行する

Saltベースのコマンドの代わりになります。

コマンド deepsea stage run ceph.stage.0は、 salt-run state.orch ceph.stage.0と同等

です。

deepsea stage runコマンドで受け付けられる利用可能なコマンドラインオプションの詳細について

は、次のマニュアルページを参照してください。

root@master # man deepsea-stage run

次の図に、ステージ2実行時のDeepSea CLIの出力の例を示します。

41 DeepSea CLI: スタンドアロンモード SES 6

図 5.1: DEEPSEA CLIのステージ実行進行状況の出力

5.4.2.1 DeepSea CLI stage runのエイリアス

Saltの上級ユーザ向けに、DeepSeaのステージを実行するためのエイリアスもサポートされています。

このエイリアスは、ステージの実行に使用するSaltコマンド(たとえば salt-run state.orch stage-

name )をDeepSea CLIのコマンドとして取ります。

例:

root@master # deepsea salt-run state.orch stage-name

42 DeepSea CLI: スタンドアロンモード SES 6

5.5 設定とカスタマイズ

5.5.1 policy.cfgファイル

/srv/pillar/ceph/proposals/policy.cfg設定ファイルは、個々のクラスタノードの役割を決定

するために使用されます。たとえば、Ceph OSDまたはCeph Monitorとして動作するノードなどです。

目的のクラスタセットアップを反映するには、 policy.cfgを編集します。セクションの順序は任意です

が、古い行の内容の一致するキーは、追加した行の内容で上書きされます。

ヒント: policy.cfgの例/usr/share/doc/packages/deepsea/examples/に、完全なポリシーファイルの例がいくつ

かあります。

5.5.1.1 クラスタの割り当て

「cluster」セクションで、クラスタのミニオンを選択します。すべてのミニオンを選択することも、ミニオン

をブラックリスト/ホワイトリストに入れることもできます。次に、「ceph」という名前のクラスタの例を示し

ます。

「すべての」ミニオンを含めるには、次の行を追加します。

cluster-ceph/cluster/*.sls

特定のミニオンを「ホワイトリスト」に入れるには、次の行を追加します。

cluster-ceph/cluster/abc.domain.sls

ミニオンのグループをホワイトリストに入れるには、シェルグロブ展開による一致を使用できます。

cluster-ceph/cluster/mon*.sls

ミニオンを「ブラックリスト」に入れるには、該当のミニオンを unassignedに設定します。

cluster-unassigned/cluster/client*.sls

43 設定とカスタマイズ SES 6

5.5.1.2 役割割り当て

このセクションでは、クラスタノードへの「役割」の割り当てについて詳しく説明します。この文脈の「役

割」とは、Ceph Monitor、Object Gateway、iSCSI Gatewayなど、ノードで実行する必要があるサー

ビスを意味します。役割は自動的には割り当てられません。 policy.cfgに追加した役割のみが展開

されます。

割り当ては次のパターンに従います。

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

ここで、各項目は次の意味と値を持ちます。

ROLE_NAMEは、「master」「admin」「mon」「mgr」「storage」「mds」「igw」「rgw」「ganesha」

「grafana」または「prometheus」のいずれかです。

PATHは、.slsファイルまたは.ymlファイルの相対ディレクトリパスです。.slsファイルの場合は通

常 clusterですが、.ymlファイルは stack/default/ceph/minionsにあります。

FILES_TO_INCLUDEは、Salt状態ファイルまたはYAML設定ファイルです。通常は、Salt

Minionのホスト名で構成されます。たとえば、 ses5min2.ymlです。シェルグロブ展開を使用し

て、さらに詳細に一致させることができます。

次に各役割の例を示します。

「master」 - このノードは、すべてのCephクラスタに対する管理キーリングを持ちます。現在のと

ころ、1つのCephクラスタのみがサポートされます。「master」役割は必須であるため、必ず次の

ような行を追加してください。

role-master/cluster/master*.sls

「admin」 - このミニオンは管理キーリングを持ちます。この役割は次のように定義します。

role-admin/cluster/abc*.sls

「mon」 - このミニオンは、Cephクラスタにモニターサービスを提供します。この役割には、割り当

てられたミニオンのアドレスが必要です。SUSE Enterprise Storage 5から、パブリックアドレス

は動的に計算されるようになり、Salt Pillarに記述する必要はなくなりました。

role-mon/cluster/mon*.sls

次の例は、モニターの役割をミニオンのグループに割り当てます。

「mgr」 - クラスタ全体からすべての状態情報を収集するCeph Managerデーモン。Ceph

Monitorの役割を展開する予定のすべてのミニオンに展開します。

44 policy.cfgファイル SES 6

role-mgr/cluster/mgr*.sls

「storage」 - この役割を使用してストレージノードを指定します。

role-storage/cluster/data*.sls

「mds」 - このミニオンは、CephFSをサポートするためのメタデータサービスを提供します。

role-mds/cluster/mds*.sls

「igw」 - このミニオンは、iSCSI Gatewayとして機能します。この役割には、割り当てられたミニ

オンのアドレスが必要です。そのため、 stackディレクトリのファイルも含める必要があります。

role-igw/cluster/*.sls

「rgw」 - このミニオンは、Object Gatewayとして機能します。

role-rgw/cluster/rgw*.sls

「ganesha」 - このミニオンは、NFS Ganeshaサーバとして機能します。「ganesha」の役割に

は、クラスタ内で「rgw」または「mds」の役割が必要です。そうしないと、ステージ3で検証に失敗

します。

role-ganesha/cluster/ganesha*.sls

NFS Ganeshaを正常にインストールするには、追加の設定が必要です。NFS Ganeshaを使用

する場合は、ステージ2および4を実行する前に、第12章「NFS Ganeshaのインストール」を読ん

でください。ただし、NFS Ganeshaは後からインストールできます。

場合によっては、NFS Ganeshaノードに対してカスタムの役割を定義すると便利です。詳細

については、『管理ガイド』、第21章「NFS Ganesha: NFS経由でのCephデータのエクスポー

ト」、21.3項「NFS Ganeshaのカスタムの役割」を参照してください。

「grafana」、「prometheus」 - このノードは、Cephダッシュボードに、Prometheusのアラート

に基づくGrafanaチャートを追加します。詳細な説明については、『管理ガイド』、第22章「Ceph

ダッシュボード」を参照してください。

role-grafana/cluster/grafana*.sls

role-prometheus/cluster/prometheus*.sls


注記: クラスタノードの複数の役割1つノードに複数の役割を割り当てることができます。たとえば、モニターノードに「mds」の役割

を割り当てることができます。

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 共通設定

共通設定のセクションには、「ディスカバリ(ステージ1)」中に生成された設定ファイルが記述されてい

ます。これらの設定ファイルには、 fsidや public_networkなどのパラメータが保存されています。必

要なCeph共通設定を含めるには、次の行を追加します。

config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml

5.5.1.4 アイテムのフィルタリング

場合によっては、*.slsグロブを使用して特定のディレクトリからすべてのファイルを含めるのは現実的で

はありません。 policy.cfgファイルパーサは次のフィルタを理解します。

警告: 高度な手法このセクションでは、上級ユーザ向けのフィルタリング手法について説明します。正しく使用しな

いと、フィルタリングによって問題が発生する可能性があります。たとえば、ノードの番号付けが

変更される場合があります。

slice=[start:end]

sliceフィルタは、「start」から「end-1」までのアイテムのみを含める場合に使用します。指定し

たディレクトリ内のアイテムは英数字順にソートされる点に注意してください。次の行は、 role-

mon/cluster/サブディレクトリから3〜5番目のファイルを含めます。

role-mon/cluster/*.sls slice[3:6]

re=regexp

正規表現フィルタは、指定した表現に一致するアイテムのみを含める場合に使用します。次に例

を示します。


role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 policy.cfgファイルの例

次に、基本的な policy.cfgファイルの例を示します。

## Cluster Assignmentcluster-ceph/cluster/*.sls 1

## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2

role-admin/cluster/sesclient*.sls 3

# MONrole-mon/cluster/ses-example-[123].sls 4

# MGRrole-mgr/cluster/ses-example-[123].sls 5

# STORAGErole-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDSrole-mds/cluster/ses-example-4.sls 7

# IGWrole-igw/cluster/ses-example-4.sls 8

# RGWrole-rgw/cluster/ses-example-4.sls 9

# COMMONconfig/stack/default/global.yml 10

config/stack/default/ceph/cluster.yml 11

1 Cephクラスタにすべてのミニオンを含めるよう指定します。Cephクラスタに含めたくないミニオン

がある場合は、次の行を使用します。

cluster-unassigned/cluster/*.slscluster-ceph/cluster/ses-example-*.sls

最初の行は、すべてのミニオンを未割り当てとしてマークします。2番目の行は、「ses-example-

*.sls」に一致するミニオンを上書きして、それらをCephクラスタに割り当てます。

2 「examplesesadmin」という名前のミニオンが「master」役割を持ちます。言い換えると、このミ

ニオンはクラスタに対する管理キーを取得します。


3 「sesclient*」に一致するすべてのミニオンも管理キーを取得します。

4 「ses-example-[123]」に一致するすべてのミニオン(おそらく、ses-example-1、ses-

example-2、およびses-example-3の3つのミニオン)がMONノードとして設定されます。

5 「ses-example-[123]」に一致するすべてのミニオン(この例ではすべてのMONノード)がMGR

ノードとして設定されます。

6 「ses-example-[5,6,7,8]」に一致するすべてのミニオンがストレージノードとして設定されます。

7 ミニオン「ses-example-4」がMDS役割を持ちます。

8 ミニオン「ses-example-4」がIGW役割を持ちます。

9 ミニオン「ses-example-4」がRGW役割を持ちます。

10 fsid 、 public_networkなどの共通設定パラメータでデフォルト値をそのまま使用することを意

味します。

11 fsid 、 public_networkなどの共通設定パラメータでデフォルト値をそのまま使用することを意

味します。

5.5.2 DriveGroups

「DriveGroups」では、CephクラスタのOSDのレイアウトを指定します。レイアウトは、1つのファイル /

srv/salt/ceph/configuration/files/drive_groups.ymlで定義します。

管理者は、相互に関連するOSDのグループ(ソリッドステートとスピナ上に展開されるハイブリッド

OSD)を手動で指定するか、同じ展開オプション(同一のオプション、たとえば、同じオブジェクトストア、

同じ暗号化オプション、スタンドアロンOSDなど)を共有する必要があります。デバイスが明示的に一

覧にされないようにするため、DriveGroupsでは、 ceph-volumeインベントリレポートで選択した数

個のフィールドに対応するフィルタ項目のリストを使用します。最も単純な場合、ここには「rotational」

フラグ(すべてのソリッドステートドライブはdb_devices、すべての回転型ドライブはデータデバイス)

か、または「model」の文字列やサイズなど、より複雑な内容を指定できます。DeepSeaでは、これらの

DriveGroupsを実際のデバイスリストに変換してユーザが調べられるようにするコードを提供します。

DriveGroups設定時の基本的なワークフローを示す単純な手順は、次のようになります。

1. ceph-volumeコマンドで表示されるディスクのプロパティを調べます。DriveGropsで受け付け

られるのは、これらのプロパティのみです。

root@master # salt-run disks.details

48 DriveGroups SES 6

2. /srv/salt/ceph/configuration/files/drive_groups.yml YAMLファイルを開き、ニー

ズに合わせて調整します。5.5.2.1項「仕様」を参照してください。必ず、タブではなくスペースを

使用してください。詳細な例については、5.5.2.4項「例」を参照してください。次の例では、使用

可能なすべてのドライブをOSDとしてCephに含めます。

default_drive_group_name: target: '*' data_devices: all: true

3. 新しいレイアウトを確認します。

root@master # salt-run disks.list

このランナは、DriveGroupsに基づいて、一致するディスクの構造を返します。結果に問題があ

る場合は、前の手順を繰り返します。

ヒント: 詳細レポートdisks.listランナのほかに、 disks.reportランナもあります。これは、次にDeepSea

ステージ3が呼び出されたときの処理について詳細レポートを出力します。

root@master # salt-run disks.report

4. OSDを展開します。次にDeepSeaステージ3が呼び出されたときに、ドライブグループの指定に

従ってOSDディスクが展開されます。

5.5.2.1 仕様

/srv/salt/ceph/configuration/files/drive_groups.ymlでは、次のオプションを指定できま

す。

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION wal_devices: drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted)


osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')

FileStoreのセットアップでは、 drive_groups.ymlは次のようになります。

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True

5.5.2.2 一致するディスクデバイス

次のフィルタを使用して指定を記述できます。

ディスクモデル別。

model: DISK_MODEL_STRING

ディスクベンダー別。

vendor: DISK_VENDOR_STRING

ヒント: 小文字のベンダー文字列DISK_VENDOR_STRINGは常に小文字で指定してください。

ディスクが回転型かどうか。SSDとNVMEのドライブは回転型ではありません。

rotational: 0

OSDで使用可能な「すべての」ドライブを使用してノードを展開します。

data_devices: all: true

また、一致するディスクの数を制限します。

limit: 10


5.5.2.3 サイズによるデバイスのフィルタリング

ディスクデバイスをサイズでフィルタできます(正確なサイズ、またはサイズの範囲)。 size:パラメータ

には、次の形式の引数を指定できます。

'10G' -正確にこのサイズのディスクを含めます。

'10G:40G' - この範囲内のサイズのディスクを含めます。

':10G' - サイズが10GB以下のディスクを含めます。

'40G:' - サイズが40GB以上のディスクを含めます。

例 5.1: ディスクサイズによる一致

drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'

注記: 引用符が必要区切り文字「:」を使用する場合は、サイズを引用符で囲む必要があります。そうしないと、「:」記

号は新しい設定のハッシュであると解釈されます。

ヒント: 単位のショートカットギガバイト(G)の代わりに、メガバイト(M)やテラバイト(T)単位でもサイズを指定できます。

5.5.2.4 例

このセクションでは、さまざまなOSDセットアップの例を示します。

例 5.2: 単純なセットアップ

この例では、同じセットアップを使用する2つのノードについて説明します。

20台のHDD


ベンダー: Intel

モデル: SSD-123-foo

サイズ: 4TB

2台のSSD

ベンダー: Micron

モデル: MC-55-44-ZX

サイズ: 512GB

対応する drive_groups.ymlファイルは次のようになります。

drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ

このような設定は単純で有効です。問題は、管理者が将来、別のベンダーのディスクを追加する

ことがあっても、そられのディスクが含まれない点です。この設定を向上させるには、ドライブのコ

アプロパティのフィルタを減らします。

drive_group_default: target: '*' data_devices: rotational: 1 db_devices: rotational: 0

前の例では、回転型デバイスはすべて「データデバイス」として宣言し、非回転型デバイスはすべ

て「共有デバイス」(wal、db)として使用します。

2TBを超えるドライブが常に低速のデータデバイスであることがわかっている場合は、サイズで

フィルタできます。

drive_group_default: target: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'


例 5.3: 詳細セットアップ

この例では、2つの別個のセットアップについて説明します。20台のHDDで2台のSSDを共有す

るセットアップと、10台のSSDで2台のNVMeを共有するセットアップです。

20台のHDD

ベンダー: Intel


サイズ: 4TB

12台のSSD



サイズ: 512GB

2つのNVMe

ベンダー: Samsung

モデル: NVME-QQQQ-987

サイズ: 256GB

このようなセットアップは、次のような2つのレイアウトで定義できます。

drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ

drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: vendor: samsung size: 256GB

例 5.4: 不均一なノードを使用した詳細セットアップ

前の例では、すべてのノードに同じドライブがあることを想定しています。ただし、常にこれが当て

はまるとは限りません。


ノード1〜5:

20台のHDD

ベンダー: Intel


サイズ: 4TB

2台のSSD



サイズ: 512GB

ノード6〜10:

5つのNVMe

ベンダー: Intel


サイズ: 4TB

20台のSSD



サイズ: 512GB

レイアウトに「target」キーを使用して、特定のノードをターゲットに設定できます。Saltのターゲッ

ト表記を使用すると、内容をシンプルに保つことができます。

drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0

続いて以下を設定します。


drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo

例 5.5: エキスパートセットアップ

前の事例はすべて、WALとDBが同じデバイスを使用することを想定していました。ただし、WAL

を専用のデバイスに展開することもできます。

20台のHDD

ベンダー: Intel


サイズ: 4TB

2台のSSD



サイズ: 512GB

2つのNVMe



サイズ: 256GB

drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987

例 5.6: 複雑な(可能性が低い)セットアップ

次のセットアップでは、以下を定義してみます。


1つのNVMeを利用する20台のHDD

1台のSSD (db)と1つのNVMe (wal)を利用する2台のHDD

1つのNVMeを利用する8台のSSD

2台SSDスタンドアロン(暗号化)

1台のHDDはスペアで、展開しない

使用するドライブの概要は次のとおりです。

23台のHDD

ベンダー: Intel


サイズ: 4TB

10台のSSD



サイズ: 512GB

1つのNVMe



サイズ: 256GB

DriveGroupsの定義は次のようになります。

drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987

drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0


db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987

drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987

drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True

ファイルが上から下へ解析されると、HDDが1台残ります。

5.5.3 カスタム設定を使用したceph.confの調整

ceph.conf設定ファイルにカスタム設定を記述する場合は、『管理ガイド』、第2章「Saltクラスタの管

理」、2.13項「カスタム設定を使用したceph.confの調整」で詳細を参照してください。

57 カスタム設定を使用したceph.confの調整 SES 6

6 古いリリースからのアップグレード

この章では、SUSE Enterprise Storage 5.5をバージョン6にアップグレードする手順について説明し

ます。バージョン5.5は、基本的にはすべての最新のパッチが適用されたバージョン5です。

注記: 古いリリースからのアップグレードはサポートされない5.5より古いバージョンのSUSE Enterprise Storageからのアップグレードはサポートされてい

ません。まず、最新バージョンのSUSE Enterprise Storage 5.5にアップグレードしてから、この

章の手順を実行する必要があります。

6.1 アップグレード前に考慮すべき点「リリースノートをお読みください」 - 旧リリースのSUSE Enterprise Storageからの変更点に関

する追加情報が記載されています。リリースノートを参照して以下を確認します。

使用しているハードウェアに特別な配慮が必要かどうか

使用しているソフトウェアパッケージに大幅な変更があるかどうか

インストールのために特別な予防措置が必要かどうか

リリースノートには、マニュアルに記載できなかった情報が記載されています。また、既知の問題に

関する注意も記載されています。

パッケージ release-notes-sesをインストールすると、リリースノートは、ローカルではディ

レクトリ /usr/share/doc/release-notesに、オンラインではhttps://www.suse.com/

releasenotes/ にあります。

以前にバージョン4からアップグレードした場合は、バージョン5へのアップグレードが正常に完了

していることを確認します。

ファイルが存在することを確認する

/srv/salt/ceph/configuration/files/ceph.conf.import

このファイルは、SES 4から5へのアップグレード中にインポートプロセスによって作成され

ます。また、 configuration_init: default-importオプションがファイルに設定され

ます。

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

58 アップグレード前に考慮すべき点 SES 6



configuration_initがまだ default-importに設定されている場合、クラスタはその

設定ファイルとして ceph.conf.importを使用しています。これは、次の場所にあるファイ

ルからコンパイルされるDeepSeaのデフォルトの ceph.confではありません。

/srv/salt/ceph/configuration/files/ceph.conf.d/

したがって、 ceph.conf.importでカスタム設定を調べ、可能であれば、次の場所にある

ファイルのいずれかに設定を移動する必要があります。

/srv/salt/ceph/configuration/files/ceph.conf.d/

その後、次のファイルから configuration_init: default-importの行を削除します。

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

警告: DeepSeaのデフォルトの設定ceph.conf.importから設定をマージして configuration_init: default-

importオプションを削除「しない」場合、DeepSeaの一部として出荷されているデ

フォルトの設定( /srv/salt/ceph/configuration/files/ceph.conf.j2に保

存)はクラスタに適用されません。

クラスタが新しいバケットタイプ「straw2」を使用しているかどうかを確認する

cephadm@adm > ceph osd crush dump | grep straw

Ceph「jewel」プロファイルが使用されていることを確認する

cephadm@adm > ceph osd crush dump | grep profile

古いRBDカーネルクライアント(SUSE Linux Enterprise Server 12 SP3より前)が使用されて

いる場合は、『管理ガイド』、第12章「RADOS Block Device」、12.9項「古いカーネルクライアン

トを使用したRVDのマッピング」を参照してください。可能であれば、古いRBDカーネルクライア

ントをアップグレードすることをお勧めします。

openATTICが管理ノード上にある場合、ノードをアップグレードするとopenATTICを使用できな

くなります。新しいCephダッシュボードは、DeepSeaを使用して展開するまで使用できません。

クラスタのアップグレードには長い時間がかかることがあります。所要時間は、1台のマシンのアッ

プグレード時間xクラスタノード数です。


SUSE Linux Enterprise Serverの旧リリースを実行している間は単一のノードをアップグレー

ドすることはできませんが、新しいバージョンのインストーラでノードを再起動する必要がありま

す。したがって、ノードが提供するサービスは、しばらくの間利用できません。コアクラスタサービス

は引き続き利用できます。たとえば、アップグレード中に1つのMONがダウンしても、アクティブな

MONはまだ少なくとも2つ存在します。残念ながら、単一のiSCSI Gatewayなど、単一インスタ

ンスのサービスは利用できなくなります。

特定のタイプのデーモンは他のデーモンに依存します。たとえば、Ceph Object Gateway

は、Ceph MONデーモンとOSDデーモンに依存します。次の順序でアップグレードすることをお

勧めします。

1. 管理ノード

2. Ceph Monitor/Ceph Manager

3. Metadata Server

4. Ceph OSD

5. Object Gateway

6. iSCSI Gateway

7. NFS Ganesha

8. Samba Gateway

AppArmorを「complain」モードまたは「enforce」モードのいずれかで使用していた場合は、

アップグレードする前にSalt Pillar変数を設定する必要があります。SUSE Linux Enterprise

Server 15 SP1にはAppArmorがデフォルトで付属しているため、DeepSeaステージ0に

AppArmorの管理が統合されました。SUSE Enterprise Storage 6では、デフォルトの動作と

してAppArmorおよび関連するプロファイルを削除します。SUSE Enterprise Storage 5.5で

設定していた動作を保持したい場合は、アップグレードを開始する前に、 /srv/pillar/ceph/

stack/global.ymlファイルに次の行のいずれかが存在することを確認してください。

apparmor_init: default-enforce



apparmor_init: default-complain

SUSE Enterprise Storage 6から、数字で始まるMDS名は使用できなくなり、MDSデーモンは

起動しなくなります。 ceph fs statusコマンドを実行するか、MDSを再起動してログで次のメッ

セージを確認することで、デーモンにこのような名前が付いているかどうかを確認できます。

deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden ina future version. MDS names may not start with a numeric digit.

上のメッセージが表示される場合は、SUSE Enterprise Storage 6へのアップグレードを試行

する前に、MDS名を移行する必要があります。DeepSeaでは、このような移行を自動化するため

のオーケストレーションが提供されています。数字で始まるMDS名の前には「mds.」が付加され

ます。

root@master # salt-run state.orch ceph.mds.migrate-numerical-names

ヒント: MDS名にバインドされているカスタム設定MDS名にバインドされている設定があり、MDSデーモンに数字で始まる名前が付いてい

る場合は、設定が新しい名前にも適用されていることを確認します(プレフィックス「mds.」

が付加されている)。例として、 /etc/ceph/ceph.confファイルの次のセクションを考え

てみます。

[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds

ceph.mds.migrate-numerical-namesオーケストレータにより、MDSデーモン名

「123-my-mds」は「mds.123-my-mds」に変更されます。新しい名前を反映するように

設定を調整する必要があります。

[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds


この処理では、新しい名前のMDSデーモンを追加してから、古いMDSデーモンを削除します。そ

のため、少しの間、MDSデーモンの数が2倍になります。クライアントは、フェールオーバーが完了

するまで少し停止した後、CephFSにアクセスできるようになります。したがって、CephFSへの負

荷がほとんどまたはまったくないと予想される時間帯に合わせてマイグレーションを計画してくだ

さい。

6.2 クラスタデータのバックアップクラスタの設定とデータのバックアップを作成することは必須ではありませんが、重要な設定ファイルと

クラスタデータをバックアップすることを強くお勧めします。詳細については、『管理ガイド』、第3章「クラ

スタ設定とデータのバックアップ」を参照してください。

6.3 ntpdからchronydへの移行SUSE Linux Enterprise Server 15 SP1では、ローカルホストの時刻の同期に ntpdが使用されな

くなりました。代わりに、 chronydが使用されます。各クラスタノードで時刻同期デーモンを移行する必

要があります。クラスタをアップグレードする「前に」 chronydへ移行することも、クラスタをアップグレー

ドしてから「後で」 chronyd に移行することもできます。

手順 6.1: クラスタをアップグレードする「前に」chronyd に移行する

1. 次のようにして chrony パッケージをインストールします。

root@minion > zypper install chrony

2. chronydの設定ファイル /etc/chrony.confを編集して、 /etc/ntp.confの現在の ntpdの

設定からNTPソースを追加します。

ヒント: chronydの設定の詳細chronydの設定にタイムソースを含める方法の詳細については、https://

documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html を参照し

てください。

3. ntpdサービスを無効にして停止します。

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

62 クラスタデータのバックアップ SES 6

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html


4. chronydサービスを開始して有効にします。

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

5. chronyのステータスを確認します。

root@minion > chronyc tracking

手順 6.2: クラスタをアップグレードした「後で」chronyd に移行する

1. クラスタのアップグレード中に、次のソフトウェアリポジトリを追加します。

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

2. クラスタをバージョン 6にアップグレードします。

3. chronydの設定ファイル /etc/chrony.confを編集して、 /etc/ntp.confの現在の ntpdの

設定からNTPソースを追加します。

ヒント: chronydの設定の詳細chronydの設定にタイムソースを含める方法の詳細については、https://

documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html を参照し

てください。

4. ntpdサービスを無効にして停止します。

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

5. chronydサービスを開始して有効にします。

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

6. ntpdから chronydに移行します。

7. chronyのステータスを確認します。

root@minion > chronyc tracking

8. アップグレードプロセス中に ntpdをシステムに保持するために追加したレガシソフトウェアリポジ

トリを削除します。

63 ntpdからchronydへの移行 SES 6



6.4 アップグレード前にクラスタにパッチを適用アップグレード前にすべてのクラスタノードに最新のパッチを適用します。

6.4.1 必要なソフトウェアリポジトリ

各クラスタのノードで必要なリポジトリが設定されていることを確認します。使用可能なすべてのリポジ

トリを一覧にするには、次のコマンドを実行します。

root@minion > zypper lr

SUSE Enterprise Storage 5.5には以下が必要です。

SLES12-SP3-Installer-Updates

SLES12-SP3-Pool

SLES12-SP3-Updates

SUSE-Enterprise-Storage-5-Pool

SUSE-Enterprise-Storage-5-Updates

SUSE Linux Enterprise Server 12 SP3上のSLE HAのNFS/SMB Gatewayには以下が必要で

す。

SLE-HA12-SP3-Pool

SLE-HA12-SP3-Updates

6.4.2 リポジトリステージングシステム

SMT、RMT、またはSUSE Managerのいずれかのリポジトリステージングシステムを使用している場

合は、現在のバージョンと新しいバージョンのSUSE Enterprise Storageに対して新しいフローズン

パッチレベルを作成します。

詳細については、以下を参照してください。

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html

https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html

https://www.suse.com/documentation/suse-manager-3/index.html

64 アップグレード前にクラスタにパッチを適用 SES 6

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html

https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html

https://www.suse.com/documentation/suse-manager-3/index.html

6.4.3 クラスタ全体への最新パッチの適用

1. 各CephクラスタノードにSUSE Enterprise Storage 5.5およびSUSE Linux Enterprise

Server 12 SP3の最新パッチを適用します。正しいソフトウェアリポジトリが各クラスタノードに接

続されていることを確認し(6.4.1項「必要なソフトウェアリポジトリ」を参照)、DeepSeaステージ

0を実行します。


2. ステージ0が完了したら、各クラスタノードのステータスに「HEALTH_OK」が含まれていることを

確認します。含まれていない場合は、次の手順で再起動する前に問題を解決してください。

3. zypper psを実行して、古いライブラリやバイナリで実行されている可能性のあるプロセスがな

いかどうかを確認し、ある場合は再起動します。

4. 実行中のカーネルが使用可能な最新のものであることを確認し、そうでない場合は再起動しま

す。次のコマンドの出力を確認します。

cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default

5. 続いて、 ceph パッケージがバージョン12.2.12以降であることを確認します。続いて、

deepsea パッケージがバージョン0.8.9以降であることを確認します。

6. 以前にいずれかの bluestore_cache設定を使用していた場合、それらの設定は、 ceph バー

ジョン12.2.10から有効ではなくなりました。新しい設定 bluestore_cache_autotuneはデ

フォルトで「true」に設定されており、キャッシュサイズの手動変更が無効になります。古い動作を

オンにするには、 bluestore_cache_autotune=falseを設定する必要があります。詳細につ

いては、『管理ガイド』、第16章「Cephクラスタの設定」、16.2.1項「自動キャッシュサイズ」を参


6.5 現在の環境の検証システムに明白な問題がある場合は、アップグレードを開始する前に修正します。アップグレード

によってシステムの既存の問題が修正されることはありません。

クラスタのパフォーマンスを確認します。 rados bench 、 ceph tell osd.*

bench 、 iperf3などのコマンドを使用できます。

ゲートウェイ(iSCSI GatewayやObject Gateway)およびRADOS Block Deviceへのアクセス

を検証します。

65 クラスタ全体への最新パッチの適用 SES 6

ネットワークのセットアップ、パーティション設定、インストールの詳細など、システムセットアップの

特定の部分を文書化します。

supportconfigを使用して重要なシステム情報を収集し、それをクラスタノードの外部に

保存します。詳細情報については、https://www.suse.com/documentation/sles-12/

book_sle_admin/data/sec_admsupport_supportconfig.html を参照してください。

各クラスタノードに十分な空きディスク容量があることを確認します。 df -hを使用して空きディ

スク容量を確認します。必要に応じて、不要なファイル/ディレクトリを削除するか、古いOSスナッ

プショットを削除して、ディスク容量を解放します。十分な空きディスク容量がない場合は、十分な

ディスク容量を解放するまで、アップグレードを続行しないでください。

6.6 クラスタの状態の確認アップグレード手順を開始する前に、 cluster healthコマンドを確認します。各クラスタノードが

「HEALTH_OK」をレポートしない限り、アップグレードを開始しないでください。

次のすべてのサービスが実行中であることを確認します。

Salt MasterおよびSalt Masterデーモン

Ceph MonitorおよびCeph Managerデーモン

Metadata Serverデーモン

Ceph OSDデーモン

Object Gatewayデーモン

iSCSI Gatewayデーモン

次の各コマンドは、クラスタの状態と特定の設定の詳細を提供します。

ceph -s

Cephクラスタのヘルス、実行中のサービス、データ使用量、およびI/O統計情報の簡単な概要を

出力します。アップグレードを開始する前に「HEALTH_OK」とレポートされることを確認します。

ceph health detail

Cephクラスタのヘルスに問題がある場合に詳細を出力します。

ceph versions

実行中のCephデーモンのバージョンを出力します。

ceph df

66 クラスタの状態の確認 SES 6

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html

クラスタの合計ディスク容量と空きディスク容量を出力します。クラスタの空きディスク容量が合

計ディスク容量の25%未満である場合は、アップグレードを開始しないでください。

salt '*' cephprocesses.check results=true

実行中のCephプロセスとそのPIDをSalt Minion別にソートして出力します。

ceph osd dump | grep ^flags

「recovery_deletes」フラグと「purged_snapdirs」フラグが存在していることを確認します。存

在していない場合は、次のコマンドを実行することで、すべての配置グループに対して強制的にス

クラブを実行できます。この強制スクラブは、Cephクライアントのパフォーマンスに悪影響を及ぼ

す可能性があることに注意してください。

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 CTDBクラスタのオフラインアップグレードCTDBは、Samba Gatewayが使用するクラスタ化データベースを提供します。CTDBプロトコルは非

常に単純であり、異なるプロトコルバージョンを使って通信するノードのクラスタをサポートしません。し

たがって、アップグレードを実行する前にCTDBノードをオフラインにする必要があります。

6.8 ノード単位のアップグレード — 基本的な手順アップグレード中にコアクラスタサービスを利用できるようにするため、クラスタノードを1つずつ

順番にアップグレードする必要があります。ノードのアップグレードは、「インストーラDVD」また

は「Distribution Migration System」の2つの方法のいずれかで実行できます。

各ノードをアップグレードした後、 rpmconfigcheckを実行して、ローカルで編集した設定ファイルの

中に、更新されたファイルがないかどうかを確認することをお勧めします。このコマンドで、サフィック

ス .rpmnew 、 .rpmorig 、または .rpmsaveが付くファイル名のリストが返された場合は、これらのファ

イルを現在の設定ファイルと比較し、ローカルでの変更が失われていないことを確認します。必要に

応じて、影響を受けるファイルを更新します。 .rpmnew 、 .rpmorig 、および .rpmsaveの各ファイルの

使用に関する詳細については、https://documentation.suse.com/sles/15-SP1/single-html/

SLES-admin/#sec-rpm-packages-manage を参照してください。

ヒント: 孤立パッケージノードをアップグレードした後、多数のパッケージが親リポジトリのない「孤立」状態になります。こ

れは、python3関連のパッケージによってpython2のパッケージが廃止されないために発生し

ます。

67 CTDBクラスタのオフラインアップグレード SES 6

https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage

https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage

孤立パッケージの一覧の詳細については、https://www.suse.com/documentation/

sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned を参


6.8.1 インストーラDVDを使用したノードの手動アップグレード

1. SUSE Linux Enterprise Server 15 SP1のインストーラDVD/イメージからノードを再起動し

ます。

2. ブートメニューから［Upgrade (アップグレード)］を選択します。

3. ［マイグレーションターゲットの選択］画面で、［SUSE Linux Enterprise Server 15 SP1］が

選択されていることを確認し、［マイグレーションリポジトリの手動調整］チェックボックスをオンに

します。

図 6.1: マイグレーションターゲットの選択

4. 次のモジュールをインストールするよう選択します。

SUSE Enterprise Storage 6 x86_64

Basesystem Module 15 SP1 x86_64

Desktop Applications Module 15 SP1 x86_64

68 インストーラDVDを使用したノードの手動アップグレード SES 6

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned

Legacy Module 15 SP1 x86_64

Server Applications Module 15 SP1 x86_64

5. ［Previously Used Repositories (以前に使用したリポジトリ)］画面で、正しいリポジトリが選

択されていることを確認します。システムがSCC/SMTに登録されていない場合は、リポジトリを

手動で追加する必要があります。

SUSE Enterprise Storage 6には以下が必要です。

SLE-Module-Basesystem15-SP1-Pool

SLE-Module-Basesystem15-SP1-Updates

SLE-Module-Server-Applications15-SP1-Pool

SLE-Module-Server-Applications15-SP1-Updates

SLE-Module-Desktop-Applications15-SP1-Pool

SLE-Module-Desktop-Applications15-SP1-Updates

SLE-Product-SLES15-SP1-Pool

SLE-Product-SLES15-SP1-Updates

SLE15-SP1-Installer-Updates

SUSE-Enterprise-Storage-6-Pool

SUSE-Enterprise-Storage-6-Updates

SESのマイグレーション後に ntpdを chronydに移行する場合は(6.3項「ntpdからchronydへ

の移行」を参照)、次のリポジトリを含めます。

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

SUSE Linux Enterprise Server 15 SP1上のSLE HAのNFS/SMB Gatewayには以下が

必要です。

SLE-Product-HA15-SP1-Pool

SLE-Product-HA15-SP1-Updates

6. ［Installation Settings (インストール設定)］を確認し、［更新］をクリックしてインストール手順

を開始します。

69 インストーラDVDを使用したノードの手動アップグレード SES 6

6.8.2 SUSE Distribution Migration Systemを使用したノードのアップグレード

DMS (「Distribution Migration System」)は、インストールされているSUSE Linux Enterpriseシ

ステムに対し、あるメジャーバージョンから別のメジャーバージョンへのアップグレードパスを提供しま

す。次の手順では、DMSを利用してSUSE Enterprise Storage 5.5をバージョン6にアップグレードし

ます。これには、基礎となるSUSE Linux Enterprise Server 12 SP3からSUSE Linux Enterprise

Server 15 SP1へのマイグレーションも含まれます。

DMSの一般的な情報と詳細情報の両方の詳細については、https://documentation.suse.com/

suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ を参


1. マイグレーションRPMパッケージをインストールします。これらのパッケージは、次の再起動時

に自動的にアップグレードをトリガするようGRUBブートローダを調整します。次のようにして

SLES15-SES-Migration および suse-migration-sle15-activation パッケージをインス

トールします。

root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation

2. a. アップグレードするノードがSCC、SMT、RMT、またはSUSE Managerなどのリポジトリス

テージングシステムに登録「されている」場合、 /etc/sle-migration-service.ymlを

次の内容で作成します。

use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

b. アップグレードするノードがSCC、SMT、RMT、またはSUSE Managerなどのリポジトリス

テージングシステムに登録「されていない」場合、次の変更を実行します。

i. 次の内容で /etc/sle-migration-service.ymlを作成します。

use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

ii. SLE 12 SP3およびSES 5のリポジトリを無効化または削除し、SLE 15 SP1およ

びSES6のリポジトリを追加します。関連するリポジトリのリストについては、6.4.1項

「必要なソフトウェアリポジトリ」を参照してください。

70 SUSE Distribution Migration Systemを使用したノードのアップ… SES 6

https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/


3. 再起動してアップグレードを開始します。アップグレードの実行中に、https://

documentation.suse.com/suse-distribution-migration-system/1.0/single-html/

distribution-migration-system/ で説明されているように、既存のSSHキーを使用し

て、 ssh経由でホストシステムから、アップグレードされたノードにマイグレーションユーザとして

ログインできます。SUSE Enterprise Storageでは、マシンに物理的にアクセスできるか、マシン

のコンソールに直接アクセスできる場合、パスワード sesupgradeを使用して、システムコンソー

ルで rootとしてログインすることもできます。アップグレード後、ノードは自動的に再起動します。

ヒント: アップグレードが失敗する場合アップグレードが失敗する場合、 /var/log/distro_migration.logを調べます。問題

を修正して、マイグレーションRPMパッケージを再インストールし、ノードを再起動します。

6.9 管理ノードのアップグレード

Salt Minionが古いバージョンのCephおよびSaltを実行していても、コマンドは salt '*'

test.pingおよび ceph statusは依然として機能します。

管理ノードをアップグレードすると、openATTICはインストールされなくなります。

管理ノードでSMTをホストしていた場合は、RMTへのマイグレーションを完了します(https://

www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html を参

照)。

6.8項「ノード単位のアップグレード — 基本的な手順」で説明されている手順を使用します。

ヒント: クラスタノードのステータス管理ノードがアップグレードされた後で、 salt-run upgrade.statusコマンドを実行して、ク

ラスタノードに関する役立つ情報を表示できます。このコマンドは、すべてのノードのCephとOS

のバージョンを一覧にし、まだ古いバージョンを実行しているノードをどのような順序でアップグ

レードすべきかを推奨します。

root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:

71 管理ノードのアップグレード SES 6




https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html

https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html

admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr) 3: data1.ceph (assigned roles: storage)[...]

6.10 Ceph Monitor/Ceph Managerノードのアップグレード

クラスタでMDSの役割を「使用しない」場合は、MON/MGRノードを1つずつアップグレードしま

す。

クラスタでMDSの役割を「使用する」場合に、MON/MGRとMDSの役割が同じ場所にあると

きは、MDSクラスタを縮小してから、同じ場所にあるノードをアップグレードします。詳細について

は、6.11項「Metadata Serverのアップグレード」を参照してください。

クラスタでMDSの役割を「使用する」場合に、それらを「専用」のサーバで実行するときは、すべて

のMON/MGRノードを1つずつアップグレードしてから、MDSクラスタを縮小してアップグレード

します。詳細については、6.11項「Metadata Serverのアップグレード」を参照してください。

注記: Ceph MonitorのアップグレードCeph Monitorの設計上の制限のため、2つのMONをSUSE Enterprise Storage 6にアッ

プグレードして定数が形成された後で、3番目のMON (まだSUSE Enterprise Storage 5.5

上に存在)が何らかの理由(ノードの再起動を含む)で再起動された場合、そのMONはMONク

ラスタに再参加しません。したがって、2つのMONがアップグレードされている場合は、残りの

MONをできるだけ早くアップグレードすることをお勧めします。


72 Ceph Monitor/Ceph Managerノードのアップグレード SES 6

6.11 Metadata ServerのアップグレードMDS (Metadata Server)クラスタを縮小する必要があります。SUSE Enterprise Storage 5.5と6の

バージョンの間には機能の互換性がないため、古いMDSデーモンは、SES 6レベルのMDSが1つクラ

スタに参加したことを確認すると、すぐにシャットダウンします。したがって、MDSノードのアップグレード

の間は、MDSクラスタを1つのアクティブなMDS (およびスタンバイなし)に縮小する必要があります。2

番目のノードがアップグレードされたらすぐに、再びMDSクラスタを拡張できます。

ヒント非常に負荷の高いMDSクラスタでは、1つのアクティブMDSでワークロードを処理できるよう

に、(たとえばクライアントを停止することにより)負荷を軽減しなければならない場合があります。

1. max_mdsオプションの現在の値を記録します。

cephadm@adm > ceph fs get cephfs | grep max_mds

2. アクティブなMDSデーモンが複数ある場合(すなわち、 max_mdsが1より大きい場合)、MDSクラ

スタを縮小します。MDSクラスタを縮小するには、次のコマンドを実行します。

cephadm@adm > ceph fs set FS_NAME max_mds 1

ここで、 FS_NAMEは、CephFSインスタンスの名前です(デフォルトは「cephfs」)。

3. スタンバイMDSデーモンの1つをホストしているノードを見つけます。 ceph fs statusコマンド

の出力を参照し、このノードのMDSクラスタのアップグレードを開始します。

cephadm@adm > ceph fs statuscephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 |

73 Metadata Serverのアップグレード SES 6

| mon2-6 |+-------------+

この例では、ノード「mon3-6」または「mon2-6」のいずれかでアップグレード手順を開始する必

要があります。

4. スタンバイMDSデーモンが存在するノードをアップグレードします。アップグレードされたMDS

ノードが起動すると、古くなったMDSデーモンは自動的にシャットダウンされます。この時点で、ク

ライアントにおいてCephFSサービスの短時間のダウンタイムが発生する場合があります。


5. 残りのMDSノードをアップグレードします。

6. max_mdsを目的の設定に再設定します。

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Ceph OSDのアップグレード各ストレージノードで次の手順に従います。

1. 特定のノードで実行されているOSDデーモンを特定します。

cephadm@osd > ceph osd tree

2. アップグレードするノードの各OSDデーモンに「noout」フラグを設定します。

cephadm@osd > ceph osd add-noout osd.OSD_ID


cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

次のコマンドで確認します。

cephadm@osd > ceph health detail | grep noout


cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN

74 Ceph OSDのアップグレード SES 6

6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

3. アップグレードするノードで次のコマンドを実行し、すべての既存のOSDに対して /etc/ceph/

osd/*.jsonファイルを作成します。

cephadm@osd > ceph-volume simple scan --force

4. OSDノードをアップグレードします。6.8項「ノード単位のアップグレード — 基本的な手順」で説

明されている手順を使用します。

5. システムで見つかったすべてのOSDを有効にします。

cephadm@osd > ;ceph-volume simple activate --all

ヒント: データパーティションの個別の有効化データパーティションを個別に有効にするには、各パーティション用の正しい ceph-

volumeコマンドを確認して、パーティションを有効にする必要があります。 X1は、パーティ

ションの正しい文字/数字に置き換えてください。

cephadm@osd > ceph-volume simple scan /dev/sdX1


cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

出力の最後の行に、パーティションを有効にするためのコマンドが含まれます。

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSIDd7bd2685-5b92-4074-8161-30d146cd0290


6. 再起動後、OSDノードが適切に起動することを確認します。

7. 「Legacy BlueStore stats reporting detected on XX OSD(s) (XX OSDで古い

BlueStore統計情報レポートが検出されました)」というメッセージに対処します。

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

Cephを14.2.2にアップグレードする場合、この警告は正常です。以下を設定して、この警告を無

効にできます。

bluestore_warn_on_legacy_statfs = false

適切な修正方法は、すべてのOSDが停止している間に、OSDで次のコマンドを実行することで

す。

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

次に、 NODE_NAMEノード上のすべてのOSDに対して ceph-bluestore-tool repairを実行す

るヘルパースクリプトを示します。

OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done

8. アップグレードするノードで、各OSDデーモンの「noout」フラグを設定解除します。

cephadm@osd > ceph osd rm-noout osd.OSD_ID


cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

次のコマンドで確認します。

cephadm@osd > ceph health detail | grep noout


メモ:

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

9. クラスタのステータスを確認します。これは次のような出力になります。

cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2

services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in

data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean

10. すべてのOSDノードを再起動したこと、および再起動後にOSDが自動的に開始したことを確認し

ます。

6.13 BlueStoreへのOSDのマイグレーションOSD BlueStoreは、OSDデーモン用の新しいバックエンドです。SUSE Enterprise Storage 5から

デフォルトのオプションになっています。FileStoreがオブジェクトをファイルとしてXFSファイルシステ

ムに保存するのに対し、BlueStoreは基礎となるブロックデバイスにオブジェクトを直接保存するので、

パフォーマンスを向上させることができます。BlueStoreでは、組み込みの圧縮、イレージャコーディン

グの上書きなど、FileStoreでは利用できないほかの機能も実現されます。

特にBlueStoreでは、OSDは「wal」(Write Ahead Log、先書きログ)デバイスと「db」(RocksDBデー

タベース)デバイスを持っています。RocksDBデータベースはBlueStore OSDのメタデータを格納しま

す。これら2つのデバイスは、デフォルトではOSDと同じデバイス上に存在しますが、いずれかを別の(た

とえば高速な)メディアに配置できます。

77 BlueStoreへのOSDのマイグレーション SES 6

SUSE Enterprise Storage 5では、FileStoreとBlueStoreの両方がサポートされており、FileStore

とBlueStoreのOSDが1つのクラスタに共存できます。SUSE Enterprise Storageのアップグレード

手順中に、FileStore OSDは自動的にBlueStoreに変換されます。BlueStoreに移行されていない

OSDではBlueStore固有の機能は利用できないので注意してください。

BlueStoreに変換する前に、OSDでSUSE Enterprise Storage 5が実行されている必要があります。

すべてのデータを2回再書き込みするので、変換には時間がかかります。このマイグレーションプロセス

の完了には長い時間がかかる可能性がありますが、クラスタの停止はなく、この時間中、すべてのクラ

イアントは引き続きクラスタにアクセスできます。ただし、マイグレーション中はパフォーマンスが低下す

ることを見込んでおいてください。これは、クラスタデータのリバランスとバックフィルが原因です。

FileStore OSDをBlueStoreに移行するには、次の手順を使用します。

ヒント: 安全対策をオフにするマイグレーションを実行するために必要なSaltコマンドは、安全対策によってブロックされます。こ

れらの予防措置をオフにするには、次のコマンドを実行します。

root@master # salt-run disengage.safety

続行する前にノードを再構築します。

root@master # salt-run rebuild.node TARGET

各ノードを個別に再構築することもできます。次に例を示します。

root@master # salt-run rebuild.node data1.ceph

rebuild.nodeは、常にノード上のすべてのOSDを削除して再作成します。

重要1つのOSDを変換できない場合、再構築を再実行すると、すでに変換済みのBlueStore

OSDが破壊されます。再構築を再実行する代わりに、次のコマンドを実行できます。

root@master # salt-run disks.deploy TARGET

BlueStoreへのマイグレーション後、オブジェクト数は同じままで、ディスク使用量もほぼ同じになりま

す。

78 BlueStoreへのOSDのマイグレーション SES 6

6.14 アプリケーションノードのアップグレード次の順序でアプリケーションノードをアップグレードします。

1. Object Gateway

Object Gatewayの前面にロードバランサがある場合は、停止なしでObject Gatewayを

ローリングアップグレードできます。

各アップグレードの後にObject Gatewayデーモンが実行されていることを確認し、S3/

Swiftクライアントを使用してテストします。

6.8項「ノード単位のアップグレード — 基本的な手順」で説明されている手順を使用しま

す。

2. iSCSI Gateway

iSCSIイニシエータがマルチパスで設定されている場合は、停止なしでiSCSI Gatewayを

ローリングアップグレードできます。

各アップグレード後に lrbdデーモンが実行されていることを検証し、イニシエータでテスト

します。

6.8項「ノード単位のアップグレード — 基本的な手順」で説明されている手順を使用しま

す。

3. NFS Ganesha。6.8項「ノード単位のアップグレード — 基本的な手順」で説明されている手順

を使用します。

4. Samba Gateway。6.8項「ノード単位のアップグレード — 基本的な手順」で説明されている手

順を使用します。

6.15 policy.cfgの更新、およびDeepSeaを使用したCephダッシュボードの展開管理ノードで、 /srv/pillar/ceph/proposals/policy.cfgを編集して、次の変更を適用します。

重要: 新しいサービスを追加しないクラスタのアップグレード中に、新しいサービスを policy.cfgファイルに追加しないでくださ

い。クラスタアーキテクチャの変更は、アップグレードが完了した後にのみ行ってください。

79 アプリケーションノードのアップグレード SES 6

1. role-openatticを削除します。

2. PrometheusおよびGrafanaがインストールされているノード(通常は管理ノード)に、 role-

prometheusおよび role-grafanaを追加します。

3. 役割 profile-PROFILE_NAMEは無視されるようになりました。対応する新しい役割であ

る role-storageの行を追加します。たとえば、次のような既存の行があるとします。

profile-default/cluster/*.sls

この場合、次の行を追加します。

role-storage/cluster/*.sls

4. すべてのSaltモジュールを同期します。

root@master # salt '*' saltutil.sync_all

5. DeepSeaステージ1およびステージ2を実行して、Salt Pillarを更新します。

root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2

6. openATTICのクリーンアップ

root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic

7. ステージ0で、まだインストールされていないiSCSI Gatewayが再起動されないようにするには、

「restart_igw」グレインを設定解除します。

Salt mastersalt '*' grains.delkey restart_igw

8. 最後に、DeepSeaステージ0〜4を実行します。

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

ヒント: ステージ3での「サブボリュームがみつからない」というエラーDeepSeaステージ3が次のようなエラーで失敗する場合があります。

80 policy.cfgの更新、およびDeepSeaを使用したCephダッシュボードの展開 SES 6

subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']

この場合、 /srv/pillar/ceph/stack/global.ymlを編集して、次の行を追加する必


subvolume_init: disabled

その後、Salt Pillarを更新し、DeepSeaステージ3を再実行します。

root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3

DeepSeaステージ3が正常に完了すると、Cephダッシュボードが実行されます。Ceph

ダッシュボードの機能の詳細な概要については、『管理ガイド』、第22章「Cephダッシュ

ボード」を参照してください。

ダッシュボードが実行されているノードを一覧にするには、次のコマンドを実行します。

cephadm@adm > ceph mgr services | grep dashboard

管理者資格情報を一覧にするには、次のコマンドを実行します。

root@master # salt-call grains.get dashboard_creds

9. 古い「civetweb」の代わりに「beast」Webサーバを使用するため、Object Gatewayサービスを

順番に再起動します。

root@master # salt-run state.orch ceph.restart.rgw.force

10. 続行する前に、Cephテレメトリモジュールを有効にすることを強くお勧めします。情報および手順

の詳細については、『管理ガイド』、第10章「Ceph Managerモジュール」、10.2項「テレメトリモ

ジュール」を参照してください。

81 policy.cfgの更新、およびDeepSeaを使用したCephダッシュボードの展開 SES 6

6.16 プロファイルベースの展開からDriveGroupsへのマイグレーションSUSE Enterprise Storage 5.5では、OSDのレイアウトを記述するため、DeepSeaによっていわゆる

「プロファイル」が提供されていました。SUSE Enterprise Storage 6から、「DriveGroups」という別

のアプローチに移行しました(詳細については、5.5.2項「DriveGroups」を参照)。

注記直ちに新しいアプローチに移行しなければならないわけではありません。 salt-run

osd.remove 、 salt-run osd.replace 、または salt-run osd.purgeなどの破壊的操作

は、引き続き使用できます。ただし、新しいOSDを追加するには、アクションが必要です。

これらの実装でアプローチが異なるため、自動マイグレーションパスは提供されていません。ただし、マ

イグレーションをできる限り簡単にするために、Saltランナなどのさまざまなツールが提供されています。

6.16.1 現在のレイアウトの分析

現在展開されているOSDの情報を表示するには、次のコマンドを使用します。

root@master # salt-run disks.discover

または、 /srv/pillar/ceph/proposals/profile-*/ディレクトリにあるファイルの内容を調べるこ

ともできます。ディレクトリは次のような構造になっています。

ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 現在のレイアウトに一致するDriveGroupsの作成

DriveGroupsの指定の詳細については、5.5.2.1項「仕様」を参照してください。

新規展開とアップグレードシナリオの違いは、移行するドライブがすでに「使用中」である点です。　

root@master # salt-run disks.list

82 プロファイルベースの展開からDriveGroupsへのマイグレーション SES 6

上のコマンドは、使われていないディスクのみを検索するため、次のコマンドを使用します。

root@master # salt-run disks.list include_unavailable=True

現在のセットアップに一致するまで、DriveGroupsを調整します。どのような状態になるかをより視覚的

に表示するには、次のコマンドを使用します。空きディスクがない場合は、何も出力されないことに注意

してください。

root@master # salt-run disks.report bypass_pillar=True

DriveGroupsが適切に設定されていることを確認し、新しいアプローチを適用する場合は、 /srv/

pillar/ceph/proposals/profile-PROFILE_NAME/ディレクトリからファイルを削除して、 /srv/

pillar/ceph/proposals/policy.cfgファイルから対応する profile-PROFILE_NAME/cluster/

*.slsの行を削除し、DeepSeaステージ2を実行してSalt Pillarを更新します。


次のコマンドを実行して、結果を確認します。

root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report

警告: DriveGroupsの誤った設定DriveGroupsが適切に設定されていない状況で、セットアップにスペアディスクがある場合、

ディスクは、指定したとおりに展開されます。次のコマンドを実行することをお勧めします。

root@master # salt-run disks.report

6.16.3 OSDの展開

スタンドアロンのOSDなどの単純なケースでは、マイグレーションは時間をかけて実行します。クラスタ

のOSDを削除するか置き換える場合は、常にLVMベースの新しいOSDで置き換えられます。

ヒント: LVM形式への移行ノードで1つの「レガシ」OSDを置き換える必要がある場合は常に、そのOSDとデバイスを共有

しているすべてのOSDをLVMベースの形式に移行する必要があります。

完全性を確保するため、ノード全体でOSDを移行することを検討してください。

83 OSDの展開 SES 6

6.16.4 より複雑なセットアップ

専用のWAL/DBや暗号化されたOSDなど、単なるスタンドアロンのOSDよりも高度なセットアップを使

用している場合は、そのWAL/DBデバイスに割り当てられているすべてのOSDを削除する場合にのみ

マイグレーションを実行できます。これは ceph-volumeコマンドによるもので、このコマンドはディスク上

に論理ボリュームを作成してから展開を行うためです。これにより、ユーザがパーティションベースの展

開とLVベースの展開を混在できないようにします。このような場合は、WAL/DBデバイスに割り当てら

れているすべてのOSDを手動で削除し、DriveGroupsアプローチを使用してOSDを再展開することを

お勧めします。

84 より複雑なセットアップ SES 6

7 デフォルト設定のカスタマイズ

ステージ2で生成されたデフォルトのクラスタ設定を変更できます(DeepSeaのステージの説明を参照

してください)。たとえば、ネットワーク設定や、管理ノードにデフォルトでインストールされるソフトウェア

の変更が必要になる場合があります。前者はステージ2の後に更新されるpillarを変更することで実行

でき、後者は通常、カスタム slsファイルを作成してpillarに追加することで実行できます。以降のセク

ションで詳細を説明します。

7.1 カスタマイズされた設定ファイルの使用このセクションでは、独自の slsファイルの追加/変更が必要なタスクを一覧にします。このような手順

は、通常、デフォルトの展開プロセスを変更する必要がある場合に使用します。

ヒント: カスタム.slsファイルにプレフィックスを付けるカスタム.slsファイルは、DeepSeaの.slsファイルと同じサブディレクトリに属します。DeepSea

パッケージから新しく追加される可能性があるファイルによって自分の.slsファイルが上書きさ

れるのを避けるため、ファイル名には custom-という文字列のプレフィックスを付けてください。

7.1.1 展開手順の無効化DeepSeaの展開プロセスの外で特定のタスクに対応するために展開プロセスをスキップする必要があ

る場合、次の例に従って「操作なし」ファイルを作成します。

手順 7.1: 時刻同期の無効化

1. 次の内容で /srv/salt/ceph/time/disabled.slsを作成して保存します。

disable time setting:test.nop

2. /srv/pillar/ceph/stack/global.ymlを編集して次の行を追加し、保存します。

time_init: disabled

3. Pillarを更新し、次の手順を実行して検証します。

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph:

85 カスタマイズされた設定ファイルの使用 SES 6

Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1

注記: 固有のIDタスクID「disable time setting」は、 slsファイル内で固有であれば、任意のメッセージ

にすることができます。固有の記述を指定することにより、IDの衝突を防ぎます。

7.1.2 展開手順の置き換え

特定の手順の動作をカスタム手順の動作に置き換える必要がある場合は、置き換え用の内容を記述

したカスタム slsファイルを作成します。

デフォルトでは、 /srv/salt/ceph/pool/default.slsは「demo」という名前のrbdイメージを作成

します。この例では、このイメージを作成するのではなく、「archive1」および「archive2」という2つのイ

メージが必要です。

手順 7.2: 2つのカスタムRBDイメージでの「DEMO」RBDイメージの置き換え

1. 次の内容で /srv/salt/ceph/pool/custom.slsを作成して保存します。

wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1

- fire_event: True

archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2

- unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True

archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True

86 展開手順の置き換え SES 6

1 「wait」モジュールは、Cephクラスタの状態が HEALTH_ERRになるまで一時停止します。新

規インストールの場合、Cephクラスタは、十分な数のOSDが利用可能になってプールの作

成が完了するまで、この状態になっていることがあります。

2 rbdコマンドはべき等ではありません。すでにイメージが存在する状態で同じ作成コマンド

を再実行すると、Saltの状態は失敗します。これを「unless」ステートメントで防止します。

2. デフォルトのファイルではなく新しく作成したカスタムファイルを呼び出すには、 /srv/pillar/

ceph/stack/ceph/cluster.ymlを編集して次の行を追加し、保存します。

pool_init: custom


root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

注記: 許可プールやイメージを作成するには十分な許可が必要です。 admin.cephミニオンは管理キーリ

ングを持っています。

ヒント: 別の方法もう1つのオプションは、代わりに /srv/pillar/ceph/stack/ceph/roles/master.ymlの

変数を変更することです。このファイルを使用すると、他のミニオンのPillarデータが乱雑になる

のを抑えることができます。

7.1.3 展開手順の変更場合によっては、追加タスクを実行するために特定の手順が必要になることがあります。関連する状態

ファイルを変更すると将来のアップグレードが複雑になる場合があるため、これはお勧めしません。代わ

りに、別個のファイルを作成して、7.1.2項「展開手順の置き換え」で説明されているものと同じ追加タ

スクを実行します。

新しい slsファイルにわかりやすい名前を付けます。たとえば、demoイメージのほかにrbdイメージを2

つ作成する必要がある場合、ファイルに archive.slsという名前を付けます。

手順 7.3: 2つの追加RBDイメージの作成

1. 次の内容で /srv/salt/ceph/pool/custom.slsを作成して保存します。

87 展開手順の変更 SES 6

include: - .archive - .default

ヒント: Includeの優先順位この例では、Saltは「archive」イメージを作成してから、「demo」イメージを作成します。

この例では順序は重要ではありません。順序を変更するには、 include:ディレクティブ

の後にある行を逆にします。

include行を archive.slsに直接追加することもできます。この場合も、すべてのイメー

ジが作成されます。ただし、include行がどこに配置されているかに関係なく、Saltは最

初に組み込みファイルの手順を処理します。「requires」ステートメントおよび「order」ス

テートメントでこの動作を上書きすることはできますが、順序は他を組み込む別個のファ

イルによって保証され、混乱が発生する可能性が抑えられます。

2. /srv/pillar/ceph/stack/ceph/cluster.ymlを編集して次の行を追加し、保存します。

pool_init: custom


root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

7.1.4 展開ステージの変更

まったく別個の展開手順を追加する必要がある場合、新しいファイルを3つ作成します。コマンドを実行

する slsファイル、オーケストレーションファイル、および新しい手順を元の手順に連動させるカスタム

ファイルです。

たとえば、準備ステージの一部として、すべてのミニオンで logrotateを実行する必要があるとします。

この場合、最初に slsファイルを作成して、 logrotateコマンドを含めます。

手順 7.4: すべてのSALT MINIONでのlogrotateの実行

1. /srv/salt/ceph/logrotateのようなディレクトリを作成します。

2. 次の内容で /srv/salt/ceph/logrotate/init.slsを作成して保存します。

rotate logs:

88 展開ステージの変更 SES 6

cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"

3. コマンドがミニオンに対して機能することを確認します。

root@master # salt 'admin.ceph' state.apply ceph.logrotate

オーケストレーションファイルは他のすべての準備手順の前に実行する必要があるため、「準備」のス

テージ0に追加します。

1. 次の内容で /srv/salt/ceph/stage/prep/logrotate.slsを作成して保存します。

logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate

2. オーケストレーションファイルが機能することを確認します。

root@master # salt-run state.orch ceph.stage.prep.logrotate

最後のファイルは、追加手順を元の手順と共に組み込むカスタムファイルです。

1. 次の内容で /srv/salt/ceph/stage/prep/custom.slsを作成して保存します。

include: - .logrotate - .master - .minion

2. デフォルトの動作を上書きします。 /srv/pillar/ceph/stack/global.ymlを編集して次の行

を追加し、ファイルを保存します。

stage_prep: custom

3. ステージ0が機能することを確認します。


注記: global.ymlを使用する理由global.ymlファイルではなく cluster.ymlを選ぶ理由は、「準備」ステージ中は、Cephクラ

スタに属しているミニオンがなく、 cluster.ymlの設定にアクセスできないためです。

89 展開ステージの変更 SES 6

7.1.5 ステージ0での更新と再起動

ステージ0 (DeepSeaステージの詳細については、DeepSeaのステージの説明を参照)の間に、オプ

ションでSalt MasterおよびSalt Minionが再起動される場合があります。これは kernelなど、新しく

更新されたパッケージでシステムの再起動が必要であるためです。

デフォルトの動作では、使用可能な新しい更新をインストールし、カーネル更新であってもノードを再起

動「しません」。

DeepSeaステージ0の更新/再起動のデフォルトの動作を変更するには、 /srv/pillar/ceph/

stack/global.ymlファイルで stage_prep_masterオプションと stage_prep_minionオ

プションを追加/変更します。 _prep_masterはSalt Masterのステージの動作を設定

し、 stage_prep_minionはすべてのMinionの動作を設定します。利用可能なすべてのパラメータは

次のとおりです。

default

再起動せずに更新をインストールします。

default-update-reboot

更新をインストールして、更新後に再起動します。

default-no-update-reboot

更新をインストールせずに再起動します。

default-no-update-no-reboot

更新のインストールまたは再起動を行いません。

たとえば、クラスタノードが更新をインストールして再起動しないようにするには、 /srv/pillar/ceph/

stack/global.ymlを編集して、次の行を追加します。

stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot

ヒント: 値および対応するファイルstage_prep_masterの値は、 /srv/salt/ceph/stage/0/masterにあるファイル名に対応

し、 stage_prep_minionの値は、 /srv/salt/ceph/stage/0/minionのファイルに対応しま

す。

root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

90 ステージ0での更新と再起動 SES 6

root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

7.2 検出された設定の変更ステージ2の完了後に、検出された設定を変更できます。現在の設定を表示するには、次のコマンドを

実行します。

root@master # salt target pillar.items

通常、1つのミニオンのデフォルト設定の出力は次のようになります。

---------- available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1

91 検出された設定の変更 SES 6

- mon2 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp

前述の各設定は、複数の設定ファイルに分散されています。これらのファイルが存在するディレクトリ構

造は、 /srv/pillar/ceph/stack/stack.cfgディレクトリに定義されます。通常、以下のファイルが

クラスタを記述します。

/srv/pillar/ceph/stack/global.yml - Saltクラスタ内のすべてのミニオンに影響します。

/srv/pillar/ceph/stack/ceph/cluster.yml - cephという名前のCephクラスタ内にある

すべてのミニオンに影響します。

/srv/pillar/ceph/stack/ceph/roles/role.yml - cephクラスタで特定の役割を割り当

てられているすべてのミニオンに影響します。

/srv/pillar/ceph/stack/ceph/minions/MINION_ID/yml - 個々のミニオンに影響します。

注記: デフォルト値でのディレクトリの上書き/srv/pillar/ceph/stack/defaultには、デフォルト設定を保存する並行ディレクトリツリー

があります。値が上書きされるため、ここで値を変更しないでください。

収集された設定の一般的な変更手順は次のとおりです。

1. 変更する必要がある設定項目の場所を見つけます。たとえば、クラスタネットワークなどのク

ラスタ関連設定を変更する必要がある場合、ファイル /srv/pillar/ceph/stack/ceph/

cluster.ymlを編集します。

2. ファイルを保存します。

3. 次のコマンドを実行して変更を確認します。

root@master # salt target saltutil.pillar_refresh

92 検出された設定の変更 SES 6

続いて、次のコマンドを実行します。

root@master # salt target pillar.items

7.2.1 Cephクラスタ展開のためのIPv6の有効化

IPv4ネットワークアドレスが一般的であるため、IPv6はカスタマイズとして有効にする必要がありま

す。DeepSeaにIPv6アドレスの自動検出機能はありません。

IPv6を設定するには、 /srv/pillar/ceph/stack/global.ymlファイルで public_network変数

と cluster_network変数を有効なIPv6サブネットに設定します。次に例を示します。

public_network: fd00:10::/64cluster_network: fd00:11::/64

その後、DeepSeaステージ2を実行し、ネットワーク情報がこの設定に一致していることを確認します。

ステージ3では、必要なフラグで ceph.confが生成されます。

重要: デュアルスタックのサポートなしCephはデュアルスタックをサポートしていません。つまり、IPv4とIPv6で同時にCephを実行す

ることはできません。DeepSeaの検証により、 public_networkと cluster_network間の不

一致や、いずれかの変数内の不一致は拒否されます。次の例では、検証に失敗します。

public_network: "192.168.10.0/24 fd00:10::/64"

ヒント: fe80::/10 link-localのアドレスを使用しないfe80::/10 link-localのアドレスは使用しないでください。 fe80のアドレスはすべてのネッ

トワークインタフェースに割り当てられており、適切なルーティングのためにはインタフェース修

飾子が必要です。サイトに割り振られたIPv6アドレスを割り当てるか、 fd00::/8を使用するこ

とを検討してください。これらはULAの一部であり、グローバルにルーティング可能ではありませ

ん。

93 Cephクラスタ展開のためのIPv6の有効化 SES 6

III 追加のサービスのインストール

8 データにアクセスするためのサービスのインストール 95

9 Ceph Object Gateway 96

10 iSCSI Gatewayのインストール 103

11 CephFSのインストール 115

12 NFS Ganeshaのインストール 130

8 データにアクセスするためのサービスのインストール

SUSE Enterprise Storage 6を展開した後、データにアクセスするために、Object GatewayやiSCSI

Gatewayなどの追加ソフトウェアをインストールしたり、Cephクラスタに追加するかたちでクラスタ化

ファイルシステムを展開したりしなければならない場合があります。この章では、主に手動インストー

ルに焦点を当てて説明します。Saltを使用してクラスタを展開した場合、特定のゲートウェイまたは

CephFSをインストールする手順については、第5章「DeepSea/Saltを使用した展開」を参照してくだ

さい。

95 SES 6

9 Ceph Object Gateway

Ceph Object Gatewayは librgw上に構築されるオブジェクトストレージインタフェースで、アプリ

ケーションにCephクラスタに対するRESTfulゲートウェイを提供します。サポートされるインタフェース

は次の2つです。

「S3互換」: Amazon S3 RESTful APIの大規模なサブセットと互換性のあるインタフェースを

持つオブジェクトストレージ機能を提供します。

「Swift互換」: OpenStack Swift APIの大規模なサブセットと互換性のあるインタフェースを持

つオブジェクトストレージ機能を提供します。

Object Gatewayデーモンは、デフォルトで「Beast」HTTPフロントエンドを使用します。これは、HTTP

の解析のためにBoost.Beastライブラリを使用し、非同期ネットワークI/OのためにBoost.Asioライブラ

リを使用します。

Object GatewayはOpenStack SwiftおよびAmazon S3と互換性があるインタフェースを提供する

ため、Object Gatewayは独自のユーザ管理機能を持ちます。Object Gatewayは、CephFSクライア

ントまたはRADOS Block Deviceクライアントからデータを保存するのに使用するものと同じクラスタ

にデータを保存できます。S3とSwiftのAPIは共通の名前空間を共有しているため、一方のAPIでデー

タを書き込んでもう一方で取得できます。

重要: DeepSeaによって展開されたObject GatewayObject GatewayはDeepSeaの役割としてインストールされるようになったため、手動でインス

トールする必要はありません。

クラスタ展開中にObject Gatewayをインストールするには、5.3項「クラスタの展開」を参照し

てください。

Object Gatewayが含まれる新しいノードをクラスタに追加するには、『管理ガイド』、第2章

「Saltクラスタの管理」、2.2項「ノードへの新しい役割の追加」を参照してください。

9.1 Object Gatewayの手動インストール1. ポート80を使用していないノードにObject Gatewayをインストールします。次のコマンドで、必

要なコンポーネントをすべてインストールします。

cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw

2. 古いObject GatewayインスタンスからApacheサーバが実行されている場合は、サーバを停止

して関連サービスを無効にします。

96 Object Gatewayの手動インストール SES 6

cephadm@ogw > sudo systemctl stop disable apache2.service

3. /etc/ceph/ceph.confを編集して次の行を追加します。

[client.rgw.gateway_host] rgw frontends = "beast port=80"

ヒントSSL暗号化を使用するようObject Gateway/Beastを設定する場合、適切に行を変更し

ます。

rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM

4. Object Gatewayサービスを再起動します。

cephadm@ogw > sudo systemctl restart [email protected]_host

9.1.1 Object Gatewayの設定

Object Gatewayを設定するには、いくつかの手順が必要です。

9.1.1.1 基本的な設定

Ceph Object Gatewayを設定するには、稼働中のCeph Storage Clusterが必要です。Ceph

Object Gatewayは、そのCeph Storage Clusterのクライアントになります。Ceph Storage Cluster

クライアントには以下が必要です。

ゲートウェイインスタンスのホスト名(たとえば、 gateway )。

適切なパーミッションを持つStorage Clusterユーザ名とキーリング。

データを保存するためのプール。

ゲートウェイインスタンスのデータディレクトリ。

Ceph設定ファイル内のインスタンスのエントリ。

97 Object Gatewayの設定 SES 6

Ceph Storage Clusterと通信するため、各インスタンスにユーザ名とキーが必要です。次の手順で

は、モニタノードを使用してブートストラップキーリングを作成してから、そのブートストラップキーリング

に基づいてObject Gatewayインスタンスのユーザキーリングを作成します。続いて、クライアントユー

ザ名とキーを作成します。その次に、そのキーをCeph Storage Clusterに追加します。最後に、ゲート

ウェイインスタンスが含まれるノードにキーリングを配布します。

1. ゲートウェイのキーリングを作成します。

cephadm@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring

2. 各インスタンスに対してCeph Object Gatewayのユーザ名とキーを生成します。例として、ここ

では client.radosgwの後に gatewayという名前を使用します。

cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. キーにケーパビリティを追加します。

cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

4. キーリングとキーを作成して、Ceph Storage Clusterへのアクセスを持つCeph Object

Gatewayを有効にしたら、そのキーをCephStorage Clusterに追加します。次に例を示します。

cephadm@adm > ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring

5. ゲートウェイインスタンスが含まれるノードにキーリングを配布します。

cephadm@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

ヒント: ブートストラップキーリングの使用もう1つの方法は、Object Gatewayのブートストラップキーリングを作成し、そこからObject

Gatewayのキーリングを作成することです。

1. モニタノードの1つでObject Gatewayのブートストラップキーリングを作成します。

cephadm@mon > ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \


--cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-NODE_HOST/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring

2. ブートストラップキーリングを保存するため、 /var/lib/ceph/radosgw/

ceph-RGW_NAMEディレクトリを作成します。

cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME

3. 新しく作成したブートストラップキーリングからObject Gatewayのキーリングを作成しま

す。

cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

4. Object GatewayのキーリングをObject Gatewayホストにコピーします。

cephadm@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

9.1.1.2 プールの作成(オプション)

Ceph Object Gatewayでは、特定のゲートウェイデータを保存するためにCeph Storage Clusterの

プールが必要です。作成したユーザが適切なパーミッションを持っている場合、プールはゲートウェイに

よって自動的に作成されます。ただし、Cephの設定ファイルで、プールごとに適切なデフォルトの数の

配置グループが設定されていることを確認してください。

プール名は ZONE_NAME.POOL_NAMEという構文に従っています。この例のように、ゲートウェイをデフォ

ルトの地域とゾーンで設定する場合、デフォルトのゾーン名は「default」になります。

.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data


プールを手動で作成するには、『管理ガイド』、第11章「ストレージプールの管理」、11.2.2項「プールの

作成」を参照してください。

重要: Object Gatewayとイレージャコーディングプールイレージャコーディングは、 default.rgw.buckets.dataプールでのみ可能です。その他の

プールはすべて複製する必要があります。そうしないとゲートウェイにアクセスできません。

9.1.1.3 Cephへのゲートウェイ設定の追加

Ceph Object Gateway設定をCephの設定ファイルに追加します。Ceph Object Gatewayの設

定では、Ceph Object Gatewayインスタンスを識別する必要があります。続いて、Ceph Object

Gatewayデーモンをインストールしたホストの名前、キーリング(cephxで使用)、およびログファイル(オ

プション)を指定します。次に例を示します。

[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring

ヒント: Object GatewayのログファイルObject Gatewayのデフォルトのログファイルを上書きするには、次の行を含めます。

log file = /var/log/radosgw/client.rgw.INSTANCE_NAME.log

ゲートウェイインスタンスの [client.rgw.*]の部分は、Cephの設定ファイルのこの部分を、Ceph

Storage Clusterクライアントの設定用として識別します。クライアントタイプはCeph Object

Gateway (radosgw)です。その後にインスタンス名が続きます。次に例を示します。

[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring

注記HOST_NAMEは、ドメイン名を除くマシンのホスト名にする必要があります。

続いて、 print continueをオフにします。これをtrueに設定すると、PUT操作で問題が発生すること

があります。


rgw print continue = false

Ceph Object GatewayをサブドメインS3呼び出し(たとえば、 http://bucketname.hostname )

と共に使用するには、Cephの設定ファイルの [client.rgw.gateway]セクションにCeph Object

GatewayのDNS名を追加する必要があります。

[client.rgw.gateway]...rgw dns name = HOST_NAME

http://BUCKET_NAME.HOST_NAME構文を使用する場合は、クライアントマシンにDnsmasqなどの

DNSサーバをインストールすることを検討する必要もあります。 dnsmasq.confファイルに以下の設定

を含める必要があります。

address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP

続いて、 CLIENT_LOOPBACK_IPのIPアドレスをクライアントマシン上の最初のDNSサーバとして追加

します。

9.1.1.4 データディレクトリの作成

展開スクリプトによってCeph Object Gatewayのデフォルトのデータディレクトリが作成されない場合

があります。まだデータディレクトリを作成していない場合は、radosgwデーモンの各インスタンスに対

して作成します。Cephの設定ファイルの host変数は、radosgwの各インスタンスをどのホストで実行

するかを指定します。一般的な形式では、radosgwデーモン、クラスタ名、およびデーモンIDを指定しま

す。

root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID

上のサンプルの ceph.conf設定を使用する場合、以下を実行します。

root # mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

9.1.1.5 サービスの再起動とゲートウェイの起動

すべてのコンポーネントが確実に設定を再ロードするよう、Ceph Storage Clusterサービスを再起動

することをお勧めします。その後、 radosgwサービスを起動します。詳細については、『管理ガイド』、第

4章「はじめに」および『管理ガイド』、第17章「Ceph Object Gateway」、17.3項「Object Gateway

サービスの操作」を参照してください。


サービスが稼働したら、匿名のGET要求を実行して、ゲートウェイが応答を返すかどうかを確認できま

す。ドメイン名に対して簡単なHTTP要求を実行すると、以下が返されるはずです。

<ListAllMyBucketsResult> <Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>


10 iSCSI Gatewayのインストール

iSCSIは、クライアント(「イニシエータ」)から、リモートサーバ上のSCSIストレージデバイス(「ター

ゲット」)にSCSIコマンドを送信できるようにするSAN (ストレージエリアネットワーク)プロトコルで

す。SUSE Enterprise Storage 6には、Cephのストレージ管理をiSCSIプロトコル経由でMicrosoft

Windows*、VMware* vSphereなどの異種クライアントから利用できるようにする機能が含まれて

います。マルチパスiSCSIアクセスによってこれらのクライアントの可用性とスケーラビリティが向上す

ると同時に、標準化されたiSCSIプロトコルがクライアントとSUSE Enterprise Storage 6クラスタ

間に追加のセキュリティ分離層も提供します。この設定機能は ceph-iscsiという名前です。Ceph

ストレージ管理者は、 ceph-iscsiを使用して、シンプロビジョニングおよび複製された高可用性ボ

リュームを定義できます。これらのボリュームでは、Ceph RBD (RADOS Block Device)により、読

み込み専用スナップショット、読み書きクローン、および自動サイズ調整がサポートされます。これによ

り、単一の ceph-iscsiゲートウェイホスト、またはマルチパスフェールオーバーをサポートする複数の

ゲートウェイホストを通じてボリュームをエクスポートできます。iSCSIプロトコルによってボリュームを

他のSCSIブロックデバイスと同じように利用できるようになり、Linux、Microsoft Windows、および

VMwareホストはiSCSIプロトコルを使用してボリュームに接続できます。つまり、SUSE Enterprise

Storage 6の顧客は、従来のSANの特徴と利点をすべて備えた完全なブロックストレージインフラスト

ラクチャサブシステムをCeph上で効果的に実行でき、将来の増加に対応できます。

この章では、CephクラスタインフラストラクチャをiSCSI Gatewayと共に設定し、クライアントホストが

iSCSIプロトコルを使ってリモート保存データをローカルストレージデバイスとして使用できるようにする

ための情報について詳しく説明します。

10.1 iSCSIブロックストレージiSCSIは、IP (インターネットプロトコル)を使用するSCSI (Small Computer System Interface)コ

マンドセットを実装したもので、RFC 3720で規定されています。iSCSIはサービスとして実装され、

クライアント(イニシエータ)はTCPポート3260でセッションを経由してサーバ(ターゲット)と通信しま

す。iSCSIターゲットのIPアドレスとポートをiSCSIポータルと呼び、1つ以上のポータルを通じてター

ゲットを公開できます。ターゲットと1つ以上のポータルの組み合わせをTPG (ターゲットポータルグ

ループ)と呼びます。

iSCSIの基礎となるデータリンク層プロトコルは一般的にEthernetです。具体的には、最新のiSCSI

インフラストラクチャは、最適なスループットのために10ギガビットEthernetまたはより高速なネット

ワークを使用します。iSCSI GatewayとバックエンドのCephクラスタ間の接続には、10ギガビット

Ethernetを強くお勧めします。

103 iSCSIブロックストレージ SES 6

10.1.1 LinuxカーネルiSCSIターゲットLinuxカーネルiSCSIターゲットは元々、プロジェクトの発端となったドメインとWebサイトの名前にち

なんでLIO for linux-iscsi.orgと呼ばれていました。しばらくの間、競合するiSCSIターゲット実装が

Linuxプラットフォームで4つも利用可能な状態が続いていましたが、最終的にはLIOがiSCSIの単一

のリファレンスターゲットとして普及しました。LIOのメインラインカーネルコードは、シンプルではあるも

のの若干あいまいな「ターゲット」という名前を用いて、「ターゲットコア」と、さまざまなフロントエンド/

バックエンドターゲットモジュールを区別しています。

最も一般的に用いられているフロントエンドモジュールはまず間違いなくiSCSIです。ただし、LIOはFC

(ファイバチャネル)、FCoE (ファイバチャネルオーバーEthernet)、およびその他の複数のフロントエン

ドプロトコルもサポートしています。現在のところ、SUSE Enterprise Storageによってサポートされて

いるのはiSCSIプロトコルのみです。

最もよく使用されるターゲットバックエンドモジュールは、ターゲットホスト上で利用可能なブロックデ

バイスを単に再エクスポートできるモジュールです。このモジュールはiblockという名前です。ただ

し、LIOには、RBDイメージへの並列化マルチパスI/Oアクセスをサポートする、RBD固有のバックエン

ドモジュールもあります。

10.1.2 iSCSIイニシエータこのセクションでは、Linux、Microsoft Windows、およびVMwareの各プラットフォームで使用されて

いるiSCSIイニシエータについて簡単に紹介します。

10.1.2.1 Linux

Linuxプラットフォームの標準のイニシエータは open-iscsiです。 open-iscsiはデーモ

ン iscsidを起動し、ユーザはこのデーモンを使用して特定のポータル上のiSCSIターゲットを検出し

てターゲットにログインし、iSCSIボリュームをマップできます。 iscsidはSCSIの中間層と通信して、

カーネル内ブロックデバイスを作成します。これにより、カーネルはこのブロックデバイスをシステムの

他のSCSIブロックデバイスと同じように扱うことができます。 open-iscsiイニシエータをデバイスマッ

パーマルチパス( dm-multipath )機能と組み合わせて展開することで、高可用性iSCSIブロックデバ

イスを提供できます。

10.1.2.2 Microsoft WindowsとHyper-V

Microsoft WindowsオペレーティングシステムのデフォルトのiSCSIイニシエータは、Microsoft

iSCSIイニシエーターです。このiSCSIサービスはGUI (グラフィカルユーザインタフェース)を使用して

設定でき、高可用性のためにマルチパスI/Oをサポートしています。

104 LinuxカーネルiSCSIターゲット SES 6

10.1.2.3 VMware

VMware vSphereおよびESXのデフォルトのiSCSIイニシエータは、VMware ESXソフトウェア

iSCSIイニシエータ vmkiscsiです。これが有効な場合、vSphere Clientから、または vmkiscsi-

toolコマンドを使用して設定できます。その後、vSphere iSCSIストレージアダプタを介してVMFSに

接続されたストレージボリュームをフォーマットし、他のVMストレージデバイスと同じように使用できま

す。VMwareイニシエータも、高可用性のためにマルチパスI/Oをサポートしています。

10.2 ceph-iscsiに関する一般情報

ceph-iscsiは、RADOS Block Deviceの利点とiSCSIのユビキタスな汎用性を組み合わせたもの

です。iSCSIターゲットホスト(iSCSI Gatewayとして知られている)上で ceph-iscsiを使用すること

で、Cephクライアントプロトコルに対応していなくても、ブロックストレージを利用する必要があるすべて

のアプリケーションがCephの利点を享受できます。代わりに、ユーザはiSCSIまたは他のターゲットフロ

ントエンドプロトコルを使用してLIOターゲットに接続できます。これにより、そのターゲットがすべてのI/

OをRBDストレージ操作に変換します。

図 10.1: 1つのISCSI GATEWAYで構成されるCEPHクラスタ

ceph-iscsiは本質的に高可用性であり、マルチパス操作をサポートしています。したがって、ダウン

ストリームのイニシエータホストは、複数のiSCSI Gatewayを使用して高可用性とスケーラビリティの

両方を実現できます。複数のゲートウェイで構成されるiSCSI設定で通信する場合、イニシエータは

iSCSI要求を複数のゲートウェイに負荷分散できます。ゲートウェイに障害が発生したり、一時的にアク

セス不可能であったり、保守のために無効になっていたりする場合、I/Oは別のゲートウェイ経由で透

過的に継続されます。

105 ceph-iscsiに関する一般情報 SES 6

図 10.2: 複数のISCSI GATEWAYで構成されるCEPHクラスタ

10.3 展開に関する考慮事項SUSE Enterprise Storage 6と ceph-iscsiの最小設定は以下のコンポーネントで構成されます。

Ceph Storage Cluster。Cephクラスタは、それぞれが8つ以上のOSD (オブジェクトストレージ

デーモン)をホストする少なくとも4台の物理サーバで構成されます。このような設定では、3つの

OSDノードがモニタ(MON)ホストとしての役割も持ちます。

LIO iSCSIターゲットを実行する1つのiSCSIターゲットサーバ。 ceph-iscsiで設定します。

1つのiSCSIイニシエータホスト。 open-iscsi (Linux)、Microsoft iSCSIイニシエーター

(Microsoft Windows)、または互換性があるその他のiSCSIイニシエータ実装を実行します。

SUSE Enterprise Storage 6と ceph-iscsiの推奨運用設定は以下で構成されます。

106 展開に関する考慮事項 SES 6

Ceph Storage Cluster。運用Cephクラスタは任意の数(通常は11以上)のOSDノードで構成

されます。一般的にはそれぞれが10〜12のOSD (オブジェクトストレージデーモン)を実行し、少

なくとも3つの専用のMONホストを持ちます。

LIO iSCSIターゲットを実行する複数のiSCSIターゲットサーバ。 ceph-iscsiで設定しま

す。iSCSIのフェールオーバーと負荷分散を行うには、これらのサーバで、 target_core_rbdモ

ジュールをサポートするカーネルを実行する必要があります。更新パッケージはSUSE Linux

Enterprise Server保守チャネルから入手できます。

任意の数のiSCSIイニシエータホスト。 open-iscsi (Linux)、Microsoft iSCSIイニシエーター

(Microsoft Windows)、または互換性があるその他のiSCSIイニシエータ実装を実行します。

10.4 インストールと環境設定このセクションでは、SUSE Enterprise StorageにiSCSI Gatewayをインストールして設定する手順

について説明します。

10.4.1 CephクラスタへのiSCSI Gatewayの展開

iSCSI Gatewayは、Cephクラスタの展開プロセス中に展開することも、DeepSeaを使用して既存のク

ラスタに追加することもできます。

クラスタ展開プロセス中にiSCSI Gatewayを組み込むには、5.5.1.2項「役割割り当て」を参照してく

ださい。

iSCSI Gatewayを既存のクラスタに追加するには、『管理ガイド』、第2章「Saltクラスタの管理」、2.2項

「ノードへの新しい役割の追加」を参照してください。

10.4.2 RBDイメージの作成

RBDイメージはCephストア内に作成され、その後iSCSIにエクスポートされます。この目的のため、専

用のRADOSプールを使用することをお勧めします。Ceph rbdコマンドラインユーティリティを使用し

てStorage Clusterに接続できる任意のホストからボリュームを作成できます。このためには、クライア

ントが少なくとも最小限のceph.conf configurationファイルとCephX認証資格情報を持っている必


以降iSCSI経由でエクスポートするために新しいボリュームを作成するには、 rbd createコマンドを

使用して、ボリュームサイズをメガバイト単位で指定します。たとえば、「iscsi-images」という名前の

プールに「testvol」という名前の100GBのボリュームを作成するには、次のコマンドを実行します。

107 インストールと環境設定 SES 6

cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'

10.4.3 iSCSI経由でのRBDイメージのエクスポート

iSCSI経由でRBDイメージをエクスポートするには、CephダッシュボードWebインタフェース

か、 ceph-iscsi gwcliユーティリティのいずれかを使用できます。このセクションでは、gwcliにのみ焦

点を当て、コマンドラインを使用してRBDイメージをエクスポートするiSCSIターゲットを作成する方法を

示します。

注記サポートされているRBDイメージ機能は、 layering 、 striping (v2) 、 exclusive-

lock 、 fast-diff 、および data-poolのみです。他の機能が有効なRBDイメージはエクス

ポートできません。

rootとして、iSCSI Gatewayのコマンドラインインタフェースを起動します。

root # gwcli

iscsi-targetsに移動して、 iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolという名前

のターゲットを作成します。

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

iSCSI Gatewayの nameと ipアドレスを指定して、ゲートウェイを作成します。

gwcli > /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/gatewaysgwcli > /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli > /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

ヒント現在の設定ノードで使用可能なコマンドのリストを表示するには、 helpコマンドを使用します。

「testvol」という名前のRBDイメージをプール「iscsi-images」に追加します。

gwcli > /iscsi-target...tvol/gateways> cd /disksgwcli > /disks> attach iscsi-images/testvol

108 iSCSI経由でのRBDイメージのエクスポート SES 6

RBDイメージをターゲットにマップします。

gwcli > /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/disksgwcli > /iscsi-target...testvol/disks> add iscsi-images/testvol

注記targetcliなどの下位レベルのツールを使用してローカル設定を照会することができますが、

設定を変更しないでください。

ヒントlsコマンドを使用して、設定を確認できます。一部の設定ノードは、 infoコマンドもサポートして

います。このコマンドを使用すると、詳細情報を表示できます。

デフォルトではACL認証が有効になっているため、このターゲットにはまだアクセスできません。認証と

アクセス制御の詳細については、10.4.4項「認証とアクセス制御」を確認してください。

10.4.4 認証とアクセス制御

iSCSI認証は柔軟性があり、多数の認証方法に対応しています。

10.4.4.1 認証なし

「認証なし」とは、イニシエータが、対応するターゲット上のすべてのLUNにアクセスできることを意味し

ます。「認証なし」を有効にするには、ACL認証を無効にします。

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> auth disable_acl

10.4.4.2 ACL認証

イニシエータ名ベースのACL認証の使用時には、定義されたイニシエータのみが接続を許可されま

す。以下を実行して、イニシエータを定義できます。

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

109 認証とアクセス制御 SES 6

定義されているイニシエータは接続できますが、イニシエータに明示的に追加されたRBDイメージに

のみアクセスできます。

gwcli > /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

10.4.4.3 CHAP認証

ACLに加えて、各イニシエータのユーザ名とパスワードを指定して、CHAP認証を有効にできます。

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli > /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

注記ユーザ名は8〜64文字の長さにし、記号は「.」、「@」、「-」、「_」、または「:」のみを使用できます。

パスワードは12〜16文字の長さにし、記号は「@」、「-」、「_」、または「/」のみを使用できます。

オプションで、 authコマンドで mutual_usernameパラメータと mutual_passwordパラメータを指定

して、CHAP相互認証を有効にすることもできます。

10.4.4.4 検出と相互認証

「検出認証」は、前の認証方法とは異なります。参照用の資格情報が必要です。これはオプションで、次

のコマンドによって設定できます。

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

注記ユーザ名は8〜64文字の長さにし、記号は「.」、「@」、「-」、「_」、または「:」のみを使用できます。

パスワードは12〜16文字の長さにし、記号は「@」、「-」、「_」、または「/」のみを使用できます。

オプションで、 discovery_authコマンドで mutual_usernameパラメータと mutual_passwordパラ

メータを指定することもできます。

検出認証は、次のコマンドを使用して無効にすることができます。

110 認証とアクセス制御 SES 6

gwcli > /iscsi-targets> discovery_auth nochap

10.4.5 詳細設定

高度なパラメータを使用して ceph-iscsiを設定し、設定したパラメータをその後LIO I/Oターゲットに

渡すことができます。パラメータは、「ターゲット」のパラメータと「ディスク」のパラメータに分かれていま

す。

警告特に明記されていない限り、これらのパラメータをデフォルト設定から変更することは推奨しま

せん。

10.4.5.1 ターゲット設定

infoコマンドを使用して、これらの設定の値を表示できます。

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolgwcli > /iscsi-target...i.x86:testvol> info

また、 reconfigureコマンドを使用して、設定を変更します。

gwcli > /iscsi-target...i.x86:testvol> reconfigure login_timeout 20

使用可能な「ターゲット」設定は次のとおりです。

default_cmdsn_depth

CmdSN (コマンドシーケンス番号)のデフォルトの深さ。特定の時点でiSCSIイニシエータが未

処理の状態にしておくことができる要求の量を制限します。

default_erl

デフォルトのエラー回復レベル。

login_timeout

ログインタイムアウトの値(秒)。

netif_timeout

NICの障害タイムアウト(秒)。

prod_mode_write_protect

1に設定すると、LUNへの書き込みを防止します。

111 詳細設定 SES 6

10.4.5.2 ディスク設定

infoコマンドを使用して、これらの設定の値を表示できます。

gwcli > /> cd /disks/rbd/testvolgwcli > /disks/rbd/testvol> info

また、 reconfigureコマンドを使用して、設定を変更します。

gwcli > /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

使用可能な「ディスク」設定は次のとおりです。

block_size

基礎となるデバイスのブロックサイズ。

emulate_3pc

1に設定すると、サードパーティコピーが有効になります。

emulate_caw

1に設定すると、Compare and Writeが有効になります。

emulate_dpo

1に設定すると、Disable Page Outがオンになります。

emulate_fua_read

1に設定すると、Force Unit Access読み込みが有効になります。

emulate_fua_write

1に設定すると、Force Unit Access書き込みが有効になります。

emulate_model_alias

1に設定すると、モデルのエイリアスに対してバックエンドデバイス名が使用されます。

emulate_pr

0に設定すると、Persistent Group Reservationを含む、SCSI予約のサポートが無効になりま

す。無効になっている間、SES iSCSI Gatewayは予約状態を無視できるため、要求の遅延が改

善されます。

ヒントiSCSIイニシエータでSCSI予約のサポートが必要ない場合は、backstore_emulate_pr

を0に設定することをお勧めします。


emulate_rest_reord

0に設定すると、Queue Algorithm ModifierにRestricted Reorderingが設定されます。

emulate_tas

1に設定すると、Task Aborted状態が有効になります。

emulate_tpu

1に設定すると、Thin Provisioning Unmapが有効になります。

emulate_tpws

1に設定すると、Thin Provisioning Write Sameが有効になります。

emulate_ua_intlck_ctrl

1に設定すると、Unit Attention Interlockが有効になります。

emulate_write_cache

1に設定すると、Write Cache Enableが有効になります。

enforce_pr_isids

1に設定すると、永続的な予約のISIDが強制されます。

is_nonrot

1に設定すると、バックストアは非ローテーションデバイスになります。

max_unmap_block_desc_count

UNMAPのブロック記述子の最大数。

max_unmap_lba_count:

UNMAPのLBAの最大数。

max_write_same_len

WRITE_SAMEの最大長。

optimal_sectors

最適な要求サイズ(セクタ単位)。

pi_prot_type

DIF保護タイプ。

queue_depth

キューの深さ。

unmap_granularity

UNMAPの細分性。


unmap_granularity_alignment

UNMAPの細分性の配置。

force_pr_aptpl

有効にすると、クライアントが aptpl=1によって要求したかどうかに関係なく、LIOは常に永続ス

トレージに「永続予約」状態を書き出します。これは、LIOのカーネルRBDバックエンドには影響し

ません。常にPR状態を永続化します。これを target_core_rbdオプションで強制的に「1」に設

定し、誰かがconfigfsで無効にしようとした場合はエラーをスローするのが理想的です。

unmap_zeroes_data

LIOがLBPRZをSCSIイニシエータにアドバタイズするかどうかに影響します。これは、マップ解

除ビットを使用したUNMAPまたはWRITE SAMEの後に、領域から0が読み込まれることを示し

ます。

10.5 tcmu-runnerを使用したRADOS Block Deviceイメージのエクスポートceph-iscsiは、 rbd (カーネルベース)および user:rbd (tcmu-runner)の両方のバックストアをサ

ポートしており、すべての管理をバックストアから独立して透過的に実行できます。

警告: 技術プレビューtcmu-runnerベースのiSCSI Gatewayの展開は現在のところ技術プレビューです。

カーネルベースののiSCSI Gatewayの展開と異なり、 tcmu-runnerベースのiSCSI Gatewayの展

開では、マルチパスI/OやSCSIの永続的な予約はサポートされません。

tcmu-runnerを使用してRADOS Block Deviceをエクスポートするには、ディスクの接続時

に user:rbdバックストアを指定することのみが必要です。

gwcli > /disks> attach rbd/testvol backstore=user:rbd

注記tcmu-runnerを使用する場合、エクスポートされたRBDイメージで exclusive-lock機能が

有効になっている必要があります。

114 tcmu-runnerを使用したRADOS Block Deviceイメージのエクスポート SES 6

11 CephFSのインストール

Ceph File System (CephFS)は、Ceph Storage Clusterを使用してデータを保存するPOSIX互換

ファイルシステムです。CephFSは、Ceph Block Deviceと同じクラスタシステム、Cephオブジェクト

ストレージとS3およびSwift API、またはネイティブのバインディング( librados )を使用します。

CephFSを使用するには、動作しているCeph Storage Clusterと、動作している「Ceph Metadata

Server」が少なくとも1つ必要です。

11.1 CephFSでサポートされるシナリオとガイドSUSE Enterprise Storage 6は、CephFSのスケールアウトと分散コンポーネントを使用するさまざま

なシナリオを正式にサポートしました。このエントリでは、ハード制限について説明し、推奨される使用事

例のガイドを提供します。

サポートされるCephFSの展開は、次の要件を満足する必要があります。

1つ以上のMetadata Server。SUSEでは、MDSの役割を持つノードを複数展開することをお

勧めします。そのうち1つだけが activeになり、残りは passiveになります。クライアントから

CephFSをマウントする際は、必ず mountコマンドですべてのMONノードを指定するようにしてく

ださい。

クライアントは、 cephfsカーネルモジュールドライバを使用する、SUSE Linux Enterprise

Server 12 SP3以降、またはSUSE Linux Enterprise Server 15以降です。FUSEモジュール

はサポートされません。

SUSE Enterprise Storage 6ではCephFSクォータがサポートされており、Cephファイルシス

テムのサブディレクトリにクォータを設定できます。クォータは、ディレクトリ階層の指定したポイン

トの下層に保存される bytesまたは filesの数を制限します。詳細については、『管理ガイド』、

第19章「クラスタ化ファイルシステム」、19.6項「CephFSのクォータの設定」を参照してください。

11.3.4項「ファイルのレイアウト」で説明されているように、CephFSはファイルレイアウトの変更

をサポートします。ただし、ファイルシステムがいずれかのクライアントによってマウントされてい

る場合は、既存のCephFSファイルシステムに新しいデータプールを追加することはできません

( ceph mds add_data_pool )。新しいデータプールはファイルシステムがアンマウントされてい

るときにのみ追加できます。

1つ以上のMetadata Server。SUSEでは、MDSの役割を持つノードを複数展開することをお勧

めします。デフォルトでは、追加のMDSデーモンが standbyデーモンとして起動し、アクティブな

MDSのバックアップとして動作します。アクティブなMDSデーモンを複数使用することもできま

す(11.3.2項「MDSのクラスタサイズ」を参照)。

115 CephFSでサポートされるシナリオとガイド SES 6

11.2 Ceph Metadata ServerCeph MDS (メタデータサーバ)は、CephFSのメタデータを保存します。Ceph Block Device と

CephオブジェクトストレージはMDSを「使用しません」。MDSにより、POSIXファイルシステムのユー

ザは、Ceph Storage Clusterに多大な負荷を掛けることなく基本的なコマンド( lsや findなど)を実

行できます。

11.2.1 Metadata Serverの追加

MDSは、最初のクラスタの展開プロセス中に展開することも(5.3項「クラスタの展開」を参照)、すでに

展開済みのクラスタに追加することもできます(『管理ガイド』、第2章「Saltクラスタの管理」、2.1項「新

しいクラスタノードの追加」を参照)。

MDSの展開後、MDSを展開したサーバのファイアウォール設定で Ceph OSD/MDSサービスを許可

します。 yastを起動し、［Security and Users (セキュリティとユーザ)］［Firewall (ファイアウォー

ル)］［Allowed Services (許可されたサービス)］へ移動して、［Service to Allow (許可するサー

ビス)］ドロップダウンメニューで［Ceph OSD/MDS］を選択します。Ceph MDSノードに完全なトラ

フィックが許可されていない場合、ほかの操作が正常に機能してもファイルシステムのマウントは失敗

します。

11.2.2 Metadata Serverの設定

ceph.conf設定ファイルに関連オプションを挿入することによって、MDSの動作を微調整できます。

METADATA SERVERの設定

mon force standby active

「true」(デフォルト)に設定した場合、モニターはスタンバイ再生を強制的にアクティブにしま

す。 [mon]セクションまたは [global]セクションで設定します。

mds cache memory limit

MDSがキャッシュに強制するソフトメモリ制限(バイト単位)。管理者は、古い mds cache

size設定ではなく、このオプションを使用する必要があります。デフォルトは1GBです。

mds cache reservation

MDSキャッシュが維持するキャッシュ予約(メモリまたはiノード単位)。MDSは、予約の修正を始

める場合、キャッシュサイズが縮小して予約が復元されるまで、クライアントの状態を取り消しま

す。デフォルトは0.05です。

mds cache size

116 Ceph Metadata Server SES 6

キャッシュするiノードの数。値0 (デフォルト)は無制限の数を示します。 mds cache memory

limitを使用して、MDキャッシュが使用するメモリの量を制限することをお勧めします。

mds cache mid

キャッシュLRU内の新しい項目の挿入ポイント(先頭から)。デフォルトは0.7です。

mds dir commit ratio

Cephが部分更新ではなくフル更新を使用してコミットを行う前にダーティであるディレクトリの割

合。デフォルトは0.5です。

mds dir max commit size

Cephが複数の小さいトランザクションに分割する前のディレクトリ更新の最大サイズ。デフォルト

は90MBです。

mds decay halflife

MDSキャッシュ温度の半減期。デフォルトは5です。

mds beacon interval

モニターに送信されるビーコンメッセージの頻度(秒単位)。デフォルトは4です。

mds beacon grace

CephがMDSの速度低下を宣言し、場合によってはそのMDSを置き換えるまでの、ビーコンなし

の間隔。デフォルトは15です。

mds blacklist interval

OSDマップ内にある、障害が発生したMDSのブラックリストの期間。この設定は、障害が発生し

たMDSデーモンがOSDマップのブラックリストに留まる時間を制御します。管理者がMDSデー

モンを手動でブラックリストに登録した場合のブラックリスト登録期間には影響しません。たとえ

ば、 ceph osd blacklist addコマンドでは、引き続きデフォルトのブラックリスト時間が使用さ

れます。デフォルトは24 * 60です。

mds reconnect timeout

MDSの再起動中にクライアントが再接続するのを待機する間隔(秒単位)。デフォルトは45です。

mds tick interval

MDSが内部の定期的なタスクを実行する頻度。デフォルトは5です。

mds dirstat min interval

統計情報がツリーの上部へ再帰的に伝播されないようにするための最小間隔(秒単位)。デフォ

ルトは1です。

mds scatter nudge interval

dirstatの変更を上へ伝播する速さ。デフォルトは5です。

117 Metadata Serverの設定 SES 6

mds client prealloc inos

各クライアントセッションに事前に割り当てるiノードの数。デフォルトは1000です。

mds early reply

ジャーナルへのコミット前にクライアントが要求結果を表示することをMDSがクライアントに許可

するかどうかを指定します。デフォルトは「true」です。

mds use tmap

ディレクトリの更新に簡易マップを使用します。デフォルトは「true」です。

mds default dir hash

ディレクトリフラグメント間でファイルをハッシュするために使用する関数。デフォルトは2です(す

なわち、「rjenkins」)。

mds log skip corrupt events

ジャーナルの再生中にMDSが、破損したジャーナルイベントをスキップしようと試みるかどうかを

指定します。デフォルトは「false」です。

mds log max events

トリミングを開始するまでのジャーナルの最大イベント数。制限を無効にするには、-1 (デフォルト)

に設定します。

mds log max segments

トリミングを開始するまでのジャーナルのセグメント(オブジェクト)の最大数。制限を無効にするに

は、-1に設定します。デフォルトは30です。

mds log max expiring

並行して失効させるセグメントの最大数。デフォルトは20です。

mds log eopen size

EOpenイベントのiノードの最大数。デフォルトは100です。

mds bal sample interval

フラグメンテーションを判断するためにディレクトリの温度をサンプリングする頻度を指定します。

デフォルトは3です。

mds bal replicate threshold

Cephがメタデータを他のモードに複製しようとするまでの最大温度。デフォルトは8000です。

mds bal unreplicate threshold

Cephがメタデータを他のノードに複製するのを停止するまでの最小温度。デフォルトは0です。

mds bal split size


MDSがディレクトリフラグメントをより小さなビットに分割するまでの最大ディレクトリサイズ。デ

フォルトは10000です。

mds bal split rd

Cephがディレクトリフラグメントを分割するまでのディレクトリ読み込みの最大温度。デフォルトは

25000です。

mds bal split wr

Cephがディレクトリフラグメントを分割するまでのディレクトリ書き込みの最大温度。デフォルトは

10000です。

mds bal split bits

ディレクトリフラグメントを分割する単位となるビット数。デフォルトは3です。

mds bal merge size

Cephが隣接するディレクトリフラグメントをマージしようとするまでの最大ディレクトリサイズ。デ

フォルトは50です。

mds bal interval

MDS間のワークロード交換の頻度(秒単位)。デフォルトは10です。

mds bal fragment interval

分割またはマージが可能なフラグメントから、フラグメンテーションの変更を実行するまでの間の

遅延(秒単位)。デフォルトは5です。

mds bal fragment fast factor

分割をただちに実行してフラグメント間隔をスキップする前に、フラグメントが分割サイズを超過で

きる比率。デフォルトは1.5です。

mds bal fragment size max

新しいエントリがENOSPCで拒否されるまでのフラグメントの最大サイズ。デフォルトは100000

です。

mds bal idle threshold

Cephがサブツリーを移行してその親に戻すまでの最小温度。デフォルトは0です。

mds bal mode

MDSの負荷を計算する方法。

0 = ハイブリッド

1 = 要求率と遅延

2 = CPUの負荷


デフォルトは0です。

mds bal min rebalance

Cephが移行するまでのサブツリーの最小温度。デフォルトは0.1です。

mds bal min start

Cephがサブツリーを検索するまでのサブツリーの最大温度。デフォルトは0.2です。

mds bal need min

許容するターゲットサブツリーサイズの最小の割合。デフォルトは0.8です。

mds bal need max

許容するターゲットサブツリーサイズの最大の割合。デフォルトは1.2です。

mds bal midchunk

Cephは、この割合のターゲットサブツリーサイズよりも大きいサブツリーを移行します。デフォルト

は0.3です。

mds bal minchunk

Cephは、この割合のターゲットサブツリーサイズのよりも小さいサブツリーを無視します。デフォ

ルトは0.001です。

mds bal target removal min

CephがMDSマップから古いMDSターゲットを削除するまでのバランサの反復処理の最小回

数。Default is 5.

mds bal target removal max

CephがMDSマップから古いMDSターゲットを削除するまでのバランサの反復処理の最大回

数。デフォルトは10です。

mds replay interval

スタンバイ再生モード(「ホットスタンバイ」)時のジャーナルのポーリング間隔。デフォルトは1で

す。

mds shutdown check

MDSのシャットダウン中にキャッシュをポーリングする間隔。デフォルトは0です。

mds thrash fragments

Cephはディレクトリをランダムにフラグメント化またはマージします。デフォルトは0です。

mds dump cache on map

CephはMDSキャッシュの内容を各MDSマップ上のファイルにダンプします。デフォルトは

「false」です。

mds dump cache after rejoin


Cephは、回復中にキャッシュに再参加した後、MDSキャッシュの内容をファイルにダンプします。

デフォルトは「false」です。

mds standby for name

MDSデーモンは、この設定で指定した名前の別のMDSデーモンを対象にしてスタンバイします。

mds standby for rank

MDSデーモンは、このランクのMDSデーモンを対象にしてスタンバイします。デフォルトは-1で

す。

mds standby replay

Ceph MDSデーモンがアクティブMDS（「ホットスタンバイ」)のログをポーリングおよび再生する

かどうかを指定します。デフォルトは「false」です。

mds min caps per client

クライアントが保持できる機能の最小数を設定します。デフォルトは100です。

mds max ratio caps per client

MDSキャッシュの要求が高いときに呼び出すことができる現在の上限の最大比率を設定しま

す。デフォルトは0.8です。

METADATA SERVER JOURNALER設定

journaler write head interval

ジャーナルヘッドオブジェクトを更新する頻度。デフォルトは15です。

journaler prefetch periods

ジャーナル再生時に先読みするストライプ期間。デフォルトは10です。

journal prezero periods

書き込み位置の前にゼロにするストライプ期間。デフォルトは10です。

journaler batch interval

人工的に発生させる追加の最大遅延(秒単位)。デフォルトは0.001です。

journaler batch max

フラッシュを遅延させる単位となるバイトの最大数。デフォルトは0です。

11.3 CephFS正常なCeph Storage Clusterと1つ以上のCeph Metadata Serverが用意できたら、Ceph File

Systemを作成してマウントできます。クライアントがネットワークに接続されていて、適切な認証キーリン

グを持っていることを確認します。

121 CephFS SES 6

11.3.1 CephFSの作成

CephFSには、「データ」と「メタデータ」にそれぞれ1つずつ、少なくとも2つのRADOSプールが必要で

す。これらのプールを設定する際には、次の点を考慮する必要があります。

メタデータプールに他より高いレプリケーションレベルを使用する。このプールのデータが失われ

ると、ファイルシステム全体がアクセス不可能になるおそれがあるためです。

メタデータプールのSSDに他よりレイテンシの低いストレージを使用する。これによって、クライア

ント上でのファイルシステム操作の体感レイテンシが向上するためです。

policy.cfgで role-mdsを割り当てると、必要なプールは自動的に作成されます。パフォー

マンスを手動で調整する場合、Metadata Serverを設定する前に、プール cephfs_dataおよ

び cephfs_metadataを手動で作成できます。これらのプールがすでに存在する場合、DeepSeaは

プールを作成しません。

プールの管理の詳細については、『管理ガイド』、第11章「ストレージプールの管理」を参照してくださ

い。

2つの必須のプール(たとえば「cephfs_data」と「cephfs_metadata」)をCephFSで使用するために

デフォルト設定で作成するには、次のコマンドを実行します。

cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num

複製プールの代わりにECプールを使用できます。ECプールは、パフォーマンス要件が低く、ランダムア

クセスが少ない用途でのみ使用することをお勧めします。たとえば、クラウドストレージやバックアップ、

アーカイブなどです。ECプール上のCephFSでBlueStoreを有効にする必要があります。また、プール

に allow_ec_overwriteオプションが設定されている必要があります。このオプションは、 ceph osd

pool set ec_pool allow_ec_overwrites trueを実行して設定できます。

イレージャコーディングでは、ファイルシステムの操作に、特に細かい更新によって多大なオーバーヘッ

ドが追加されます。このオーバーヘッドは、イレージャコーディングを耐障害性メカニズムとして使用す

る場合につきものです。このペナルティは、ストレージ領域へのオーバーヘッドが大幅に削減されること

のトレードオフです。

プールが作成されたら、 ceph fs newコマンドを使用してファイルシステムを有効にできます。

cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name


cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data

ファイルシステムが作成されたかどうかを確認するには、利用可能なすべてのCephFSを一覧にしま

す。

122 CephFSの作成 SES 6

cephadm@adm > ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

ファイルシステムが作成されている場合、MDSを「アクティブ」状態にすることができます。たとえば、1

つのMDSシステムの場合、次のようになります。

cephadm@adm > ceph mds state5: 1/1/1 up

ヒント: その他のトピックマウント、アンマウント、CephFSの高度な設定など、特定のタスクの詳細情報は、『管理ガイド』、

第19章「クラスタ化ファイルシステム」に記載されています。

11.3.2 MDSのクラスタサイズ

1つのCephFSインスタンスに複数のアクティブなMDSデーモンでサービスを提供できます。CephFS

インスタンスに割り当てられているすべてのアクティブなMDSデーモンは、デーモン間でシステム

のディレクトリツリーを分散して同時クライアントの負荷を分散します。アクティブなMDSデーモンを

CephFSインスタンスに追加するには、スペアのスタンバイが必要です。追加のデーモンを起動するか、

既存のスタンバイインスタンスを使用します。

次のコマンドは、アクティブなMDSデーモンとパッシブなデーモンの現在の数を表示します。

cephadm@adm > ceph mds stat

次のコマンドは、1つのファイルシステムインスタンスでアクティブなMDSの数を2に設定します。

cephadm@adm > ceph fs set fs_name max_mds 2

更新前にMDSクラスタを縮小するには、2つの手順が必要です。最初に、 max_mdsを設定し、1つのイ

ンスタンスだけが残るようにします。

cephadm@adm > ceph fs set fs_name max_mds 1

その後、他のアクティブなMDSデーモンを明示的に無効にします。

cephadm@adm > ceph mds deactivate fs_name:rank

ここで、 rankは、ファイルシステムインスタンスのアクティブなMDSデーモンの数で、0〜 max_mds -1

の範囲になります。

123 MDSのクラスタサイズ SES 6

少なくとも1つのMDSをスタンバイデーモンとして残すことをお勧めします。

11.3.3 MDSクラスタと更新

Cephの更新中に、ファイルシステムインスタンスの機能フラグが変更されることがあります(通常、新機

能の追加によって発生します)。互換性のないデーモン(古いバージョンなど)は、互換性のない機能セッ

トでは機能できず、起動を拒否します。つまり、1つのデーモンを更新して再起動すると、まだ更新されて

いない他のデーモンがすべて停止して起動を拒否する可能性があります。このような理由から、Cephを

更新する前に、アクティブなMDSクラスタのサイズを1に縮小して、スタンバイデーモンをすべて停止す

ることをお勧めします。この更新手順を手動で実行するための手順は次のとおりです。

1. zypperを使用してCeph関連パッケージを更新します。

2. 上の説明のように、アクティブなMDSクラスタを1つのインスタンスに減らし、他のすべてのノード

で systemdユニットを使用してスタンバイMDSデーモンをすべて停止します。

cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target

3. その後、残っている1つのMDSデーモンを再起動し、更新されたバイナリで再起動させます。

cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target

4. 他のすべてのMDSデーモンを再起動して、必要な max_mds設定を再設定します。

cephadm@mds > systemctl start ceph-mds.target

DeepSeaを使用している場合、 ceph パッケージがステージ0〜4の間に更新されていれ

ば、DeepSeaはこの手順に従います。この手順は、クライアントがCephFSインスタンスをマウントして

いてI/Oが実行中であっても行うことができます。ただし、アクティブなMDSの再起動中はI/Oが短時

間一時停止するので注意してください。クライアントは自動的に回復します。

MDSクラスタを更新する前に、できる限りI/O負荷を削減することをお勧めします。アイドル状態の

MDSクラスタでは、この更新手順はより短時間で完了します。逆に、複数のMDSデーモンが存在する

非常に負荷の高いクラスタでは、実行中のI/Oによって1つのMDSデーモンが圧迫されるのを避ける

ため、前もって負荷を軽減しておくことが不可欠です。

11.3.4 ファイルのレイアウト

ファイルのレイアウトは、その内容をCeph RADOSオブジェクトにマップする方法を制御します。「仮想

拡張属性」(短縮形は「xattrs」)を使用してファイルのレイアウトを読み書きできます。

124 MDSクラスタと更新 SES 6

レイアウトxattrsの名前は、ファイルが通常のファイルでるか、それともディレクトリであるかによって異

なります。通常のファイルのレイアウトxattrsは ceph.file.layoutと呼ばれ、ディレクトリのレイアウト

xattrsは ceph.dir.layoutと呼ばれます。例が ceph.file.layoutを参照している場合にディレクト

リを処理するときは、 .dir.の部分を適切に置き換えてください。

11.3.4.1 レイアウトフィールド

次の属性フィールドが認識されます。

pool

ファイルのデータオブジェクトが保存されるRADOSプールのIDまたは名前。

pool_namespace

オブジェクトの書き込み先のデータプール内のRADOSネームスペース。これはデフォルトでは

空で、デフォルトのネームスペースを意味します。

stripe_unit

ファイルのRAID 0分散で使用するデータブロックのサイズ(バイト単位)。ファイルのストライプ単

位はすべて同じサイズです。通常、最後のストライプ単位は不完全です。これは、ファイルの終わ

りにあるデータと、ファイルの終わりを超えて固定ストライプ単位サイズの終わりまでの未使用の

「領域」を表しています。

stripe_count

ファイルデータのRAID 0「ストライプ」を構成する、連続するストライプ単位の数。

object_size

ファイルデータがチャンクされるRADOSオブジェクトのサイズ(バイト単位)。

ヒント: オブジェクトサイズRADOSでは、設定可能な制限がオブジェクトサイズに適用されます。CephFSのオブ

ジェクトサイズをその制限を超えて増やすと、書き込みが正常に実行されない場合があり

ます。OSD設定は、 osd_max_object_sizeで、デフォルトでは128MBです。RADOSオ

ブジェクトが非常に大きいと、クラスタのスムーズな操作を妨げる場合があるため、デフォ

ルト値を超えてオブジェクトサイズの制限を増やすことは推奨しません。

125 ファイルのレイアウト SES 6

11.3.4.2 getfattrを使用したレイアウトの読み込み

getfattrコマンドを使用して、1つの文字列としてサンプルファイル fileのレイアウト情報を読み込み

ます。

root # touch fileroot # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430

個々のレイアウトフィールドを読み込みます。

root # getfattr -n ceph.file.layout.pool file# file: fileceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"

ヒント: プールIDまたは名前レイアウトを読み込む場合、プールは通常、名前で示されます。ただし、プールが作成されたばか

りのまれなケースでは、代わりにIDが出力される場合があります。

カスタマイズしない限り、ディレクトリに明示的なレイアウトはありません。レイアウトを変更していない場

合、レイアウトを読み込もうとすると失敗します。これは、明示的なレイアウトを持つ次の先祖ディレクトリ

が使用されることを示します。

root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 setfattrを使用したレイアウトの書き込み

setfattrコマンドを使用して、サンプルファイル fileのレイアウトフィールドを変更します。

cephadm@adm > ceph osd lspools0 rbd1 cephfs_data


2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file

注記: 空のファイルsetfattrを使用してファイルのレイアウトフィールドを変更する場合、このファイルは空である

必要があります。空でない場合、エラーが発生します。

11.3.4.4 レイアウトのクリア

サンプルディレクトリ mydirから明示的なレイアウトを削除して元に戻し、その先祖のレイアウトを継承さ

せるには、次のコマンドを実行します。

root # setfattr -x ceph.dir.layout mydir

同様に、「pool_namespace」属性が設定されている状況で、代わりにデフォルトのネームスペースを

使用するようにレイアウトを変更する場合は、次のコマンドを実行します。

# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"

# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"

11.3.4.5 レイアウトの継承

ファイルは、作成時にその親ディレクトリのレイアウトを継承します。ただし、それ以降に親ディレクトリの

レイアウトを変更しても、子には影響しません。

root # getfattr -n ceph.dir.layout dir# file: dir


ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# file1 inherits its parent's layoutroot # touch dir/file1root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2

# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

ディレクトリの子孫として作成されたファイルも、中間ディレクトリにレイアウトが設定されていなければ、

そのレイアウトを継承します。

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attributeroot # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

11.3.4.6 Metadata Serverへのデータプールの追加

CephFSでプールを使用する前に、そのプールをMetadata Serverに追加する必要があります。

cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up


.... data pools: [cephfs_data cephfs_data_ssd ]

ヒント: cephxキー使用しているcephxキーでクライアントがこの新しいプールにアクセスできることを確認します。

次に、追加したプールを使用するようにCephFSのディレクトリのレイアウトを更新できます。

root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir

そのディレクトリ内で作成された新しいファイルはすべてそのレイアウトを継承し、新しく追加したプール

にそのデータを配置できるようになります。新しく追加したプール内でファイルを作成した場合でも、プラ

イマリデータプールのオブジェクトの数が増え続けることに気付くことがあります。これは正常です。ファ

イルデータはレイアウトで指定されたプールに保存されますが、すべてのファイルについて、少量のメタ

データがプライマリデータプールに保持されます。


12 NFS Ganeshaのインストール

NFS Ganeshaは、Object GatewayまたはCephFSにNFSアクセスを提供します。SUSE

Enterprise Storage 6では、NFSバージョン3と4がサポートされています。NFS Ganeshaはカーネ

ル空間ではなくユーザ空間で動作し、Object GatewayまたはCephFSと直接対話します。

警告: クロスプロトコルアクセスネイティブのCephFSおよびNFSクライアントは、Sambaを介して取得されるファイルロックによ

る制限を受けません。また、その逆も同様です。クロスプロトコルファイルロックに依存するアプリ

ケーションでは、CephFSを利用するSamba共有パスに他の手段でアクセスした場合、データ

の破壊が発生することがあります。

12.1 準備

12.1.1 一般情報

NFS Ganeshaを正しく展開するには、 /srv/pillar/ceph/proposals/policy.cfgに role-

ganeshaを追加する必要があります。詳細については、5.5.1項「policy.cfgファイル」を参照してくだ

さい。さらに、 policy.cfgに role-rgwまたは role-mdsも存在する必要があります。

すでに存在するCephノードにNFS Ganeshaサーバをインストールして実行することはできます

が、Cephクラスタにアクセスできる専用のホストで実行することをお勧めします。通常、クライアントホ

ストはクラスタには含まれませんが、NFS Ganeshaサーバに対するネットワークアクセスが必要です。

NFS Ganeshaサーバを初期インストール後の任意の時点で有効にするには、 policy.cfgに role-

ganeshaを追加して、少なくともDeepSeaのステージ2および4をもう一度実行します。詳細について

は、5.3項「クラスタの展開」を参照してください。

NFS Ganeshaの設定には、NFS Ganeshaノードに存在するファイル /etc/ganesha/

ganesha.confを使用します。ただし、このファイルはDeepSeaステージ4を実行するたびに上書き

されます。したがって、Saltが使用するテンプレートを編集することをお勧めします。このテンプレート

は、Salt Master上にあるファイル /srv/salt/ceph/ganesha/files/ganesha.conf.j2です。設

定ファイルの詳細については、『管理ガイド』、第21章「NFS Ganesha: NFS経由でのCephデータのエ

クスポート」、21.2項「設定」を参照してください。

130 準備 SES 6

12.1.2 要件の概要

DeepSeaステージ2および4を実行してNFS Ganeshaをインストールするには、以下の要件を満たす

必要があります。

少なくとも1つのノードに role-ganeshaが割り当てられている必要があります。

1つのミニオンに定義できる role-ganeshaは1つだけです。

NFS Ganeshaが動作するにはObject GatewayまたはCephFSが必要です。

role-ganeshaの役割を持つミニオンでは、カーネルベースのNFSを無効にする必要がありま

す。

12.2 インストールの例この手順では、Object GatewayとNFS GaneshaのCephFS FSAL (File System Abstraction

Layers)の両方を使用するインストールの例について説明します。

1. DeepSeaステージ0と1をまだ実行していない場合は、この手順に進む前に実行します。


2. DeepSeaステージ1の実行後、 /srv/pillar/ceph/proposals/policy.cfgを編集して次

の行を追加します。

role-ganesha/cluster/NODENAME

NODENAMEは実際のクラスタのノード名に置き換えてください。

さらに、 role-mdsと role-rgwが割り当てられていることを確認します。

3. 少なくともDeepSeaステージ2と4を実行します。その間にステージ3を実行することをお勧めし

ます。

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4

4. NFS Ganeshaサービスがミニオンノードで実行されていることを確認することで、NFS

Ganeshaが動作していることを確認します。

root@master # salt -I roles:ganesha service.status nfs-ganesha

131 要件の概要 SES 6

MINION_ID: True

12.3 高可用性のアクティブ-パッシブ設定このセクションでは、NFS Ganeshaサーバの2ノードのアクティブ-パッシブ設定を行う方法について例

を挙げて説明します。このセットアップでは、SUSE Linux Enterprise High Availability Extension

が必要です。これら2つのノードは、 earthおよび marsという名前です。

重要: サービスのコロケーション独自の耐障害性と独自の負荷分散機能を持つサービスは、フェールオーバーサービス

のためにフェンシングされるクラスタノードでは実行しないでください。したがって、Ceph

Monitor、Metadata Server、iSCSI、またはCeph OSDの各サービスは、高可用性セットアッ

プでは実行しないでください。

SUSE Linux Enterprise High Availability Extensionの詳細については、https://

www.suse.com/documentation/sle-ha-15/ を参照してください。

12.3.1 基本的なインストール

このセットアップでは、 earthにIPアドレス 192.168.1.1 、 marsにアドレス 192.168.1.2が設定され

ています。

さらに、2つの浮動仮想IPアドレスが使用されており、実行している物理ノードがどれであれ、クライアン

トからの該当サービスへの接続が可能になります。Hawk2でのクラスタ管理には 192.168.1.10を使

用し、NFSエクスポートには 192.168.2.1を排他的に使用します。これにより、後で簡単にセキュリティ

制約を適用できます。

次の手順では、インストールの例について説明します。詳細については、https://www.suse.com/

documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html を参


1. Salt Master上にNFS Ganeshaノードを準備します。

a. DeepSeaステージ0および1を実行します。


132 高可用性のアクティブ-パッシブ設定 SES 6

https://www.suse.com/documentation/sle-ha-15/

https://www.suse.com/documentation/sle-ha-15/



b. /srv/pillar/ceph/proposals/policy.cfgでノード earthおよび marsに role-

ganeshaを割り当てます。

role-ganesha/cluster/earth*.slsrole-ganesha/cluster/mars*.sls

c. DeepSeaステージ2〜4を実行します。

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

2. earthおよび marsでSUSE Linux Enterprise High Availability Extensionを登録します。

root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

3. 両方のノードに ha-cluster-bootstrap をインストールします。

root # zypper in ha-cluster-bootstrap

4. a. earthでクラスタを初期化します。

root@earth # ha-cluster-init

b. marsをクラスタに参加させます。

root@mars # ha-cluster-join -c earth

5. クラスタの状態を確認します。クラスタに2つのノードが追加されたことがわかります。

root@earth # crm status

6. 両方のノードで、起動時のNFS Ganeshaサービスの自動起動を無効にします。

root # systemctl disable nfs-ganesha

7. earthで crmシェルを起動します。

root@earth # crm configure

以降のコマンドはcrmシェルで実行されます。

8. earthで、crmシェルを実行して次のコマンドを実行し、NFS Ganeshaデーモンのリソースを

systemdリソースタイプのクローンとして設定します。

133 基本的なインストール SES 6

crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \op monitor interval=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure# commitcrm(live)configure# status 2 nodes configured 2 resources configured

Online: [ earth mars ]

Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]

9. crmシェルでプリミティブIPAddr2を作成します。

crm(live)configure# primitive ganesha-ip IPaddr2 \params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \op monitor interval=10 timeout=20

crm(live)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth

10. NFS Ganeshaサーバと浮動仮想IPとの間の関係を設定するため、コロケーションと順序付けを

使用します。

crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip

11. クライアントから mountコマンドを使用して、クラスタのセットアップが完了していることを確認し

ます。

root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 リソースのクリーンアップいずれかのノード(たとえば、 earth )でNFS Ganeshaに障害が発生した場合、問題を修正してリソー

スをクリーンアップします。 marsでNFS Ganeshaに障害が発生した場合、リソースをクリーンアップし

た後でのみ、リソースを earthにフェールバックできます。

134 リソースのクリーンアップ SES 6

リソースをクリーンアップするには、次のコマンドを実行します。

root@earth # crm resource cleanup nfs-ganesha-clone earthroot@earth # crm resource cleanup ganesha-ip earth

12.3.3 Pingリソースの設定

ネットワークの問題により、サーバがクライアントにアクセスできなくなることがあります。Pingリソースに

よってこの問題を検出および緩和できます。このリソースの設定はオプションです。

1. Pingリソースを定義します。

crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60

host_listは、IPアドレスをスペース文字で区切ったリストです。これらのIPアドレスに定期的に

pingが送信されて、ネットワークが停止していないかどうかが確認されます。クライアントが常に

NFSサーバにアクセスできる必要がある場合は、そのクライアントを host_listに追加します。

2. クローンを作成します。

crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true

3. 次のコマンドは、NFS Ganeshaサービスに対して制約を作成します。これにより、 host_listが

アクセス不可能になった場合、サービスを強制的に別のノードに移動します。

crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0

12.3.4 NFS Ganesha HAとDeepSea

DeepSeaでは、NFS Ganesha HAの設定はサポートされていません。NFS Ganesha HAの設定後

にDeepSeaで障害が発生するのを防止するには、DeepSeaステージ4からNFS Ganeshaサービス

の起動と停止を除外します。

1. /srv/salt/ceph/ganesha/default.slsを /srv/salt/ceph/ganesha/ha.slsにコピー

します。

135 Pingリソースの設定 SES 6

2. /srv/salt/ceph/ganesha/ha.slsから .serviceエントリを削除し、次のようにします。

include:- .keyring- .install- .configure

3. /srv/pillar/ceph/stack/global.ymlに次の行を追加します。

ganesha_init: ha

12.4 アクティブ-アクティブ設定このセクションでは、NFS Ganeshaのシンプルなアクティブ-アクティブセットアップの例を説明しま

す。この目的は、同じ既存のCephFSの上に階層化された2つのGaneshaサーバを展開することです。

サーバは別個のアドレスを持つ2つのCephクラスタノードになります。クライアントは、それらの間で手

動で分散する必要があります。この設定における「フェールオーバー」とは、他方のサーバをクライアント

で手動でアンマウントして再マウントすることを意味します。

12.4.1 前提条件

このサンプル設定では、以下が必要です。

稼働中のCephクラスタ。DeepSeaを使用してCephクラスタを展開および設定する場合の詳細

については、5.3項「クラスタの展開」を参照してください。

少なくとも1つの設定済みのCephFS。CephFSの展開と設定の詳細については、第11章

「CephFSのインストール」を参照してください。

NFS Ganeshaが展開されている2つのCephクラスタノード。NFS Ganeshaの展開の詳細につ

いては、第12章「NFS Ganeshaのインストール」を参照してください。

ヒント: 専用のサーバを使用するNFS Ganeshaノードで他のCeph関連サービスとリソースを共有することはできますが、

パフォーマンスを向上させるため、専用のサーバを使用することをお勧めします。

NFS Ganeshaノードを展開した後、クラスタが動作可能で、デフォルトのCephFSプールが存在してい

ることを確認します。

136 アクティブ-アクティブ設定 SES 6

cephadm@adm > rados lspoolscephfs_datacephfs_metadata

12.4.2 NFS Ganeshaの設定

両方のNFS Ganeshaノードにファイル /etc/ganesha/ganesha.confがインストールされていること

を確認します。まだ存在しない場合は、RADOSをNFS Ganeshaの回復バックエンドとして有効にする

ため、設定ファイルに次のブロックを追加します。

NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{ RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}

次の形式の設定で既存の行を確認すると、 rados_poolおよび pool_namespaceの値を確認できま

す。

%url rados://rados_pool/pool_namespace/...

nodeidオプションの値はマシンのFQDNに対応しており、 UserIdオプションと Ceph_Confオプショ

ンの値は既存の RADOS_URLSブロックで確認できます。

NFSのレガシバージョンでは、猶予期間を早期に解除できないためサーバの再起動が長引くという理

由から、バージョン4.2より前のNFSのオプションは無効にしています。また、Cephライブラリはすでに

積極的なキャッシュを行っているため、NFS Ganeshaのほとんどのキャッシュも無効にしています。

137 NFS Ganeshaの設定 SES 6

「rados_cluster」回復バックエンドは、その情報をRADOSオブジェクトに保存します。このデータは大

量ではありませんが、このデータにも高可用性が必要です。このためにCephFSメタデータプールを使

用し、CephFSオブジェクトから区別するために、そこで新しい「ganesha」ネームスペースを宣言しま

す。

注記: クラスタノードID大半の設定は2つのホストで同一ですが、「RADOS_KV」ブロックの nodeidオプションは、各

ノードで固有の文字列にする必要があります。デフォルトでは、NFS Ganeshaは nodeidをノー

ドのホスト名に設定します。

ホスト名以外の異なる固定値を使用する必要がある場合は、たとえば一方のノードに nodeid

= 'a'を設定し、他方のノードに nodeid = 'b'を設定できます。

12.4.3 クラスタ猶予データベースへの入力クラスタ内のすべてのノードがお互いを認識していることを確認する必要があります。これは、ホスト間

で共有されるRADOSオブジェクトを介して実行します。NFS Ganeshaは、このオブジェクトを使用し

て、猶予期間に関する現在の状態を伝達します。

このデータベースのクエリおよび操作を行うためのコマンドラインツールは、 nfs-ganesha-rados-

grace パッケージに含まれています。このパッケージが少なくとも1つのノードにインストールされてい

ない場合は、次のコマンドを使用してインストールします。

root # zypper install nfs-ganesha-rados-grace

このコマンドを使用してDBを作成し、両方の nodeidを作成します。この例では、2つのNFS Ganesha

ノードに、 ses6min1.example.comおよび ses6min2.example.comという名前が付いています。一

方のNFS Ganeshaホストで、次のコマンドを実行します。

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E

これにより、猶予データベースが作成され、「ses6min1.example.com」と

「ses6min2.example.com」の両方がデータベースに追加されます。最後のコマンドは、現在の状態を

ダンプします。新しく追加したホストは常に猶予期間が適用されていると見なされるため、両方に「E」フ

ラグが設定されています。「cur」および「rec」の値は、現在のエポックと回復エポックを示しており、これ

により、どのホストがいつ回復を実行できるかを追跡できます。

138 クラスタ猶予データベースへの入力 SES 6

12.4.4 NFS Ganeshaサービスの再起動

両方のNFS Ganeshaノードで、関連するサービスを再起動します。

root # systemctl restart nfs-ganesha.service

サービスが再起動したら、猶予データベースを確認します。

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0======================================================ses6min1.example.comses6min2.example.com

注記: 「E」フラグのクリア両方のノードで「E」フラグがクリアされていることに注意してください。これは、ノードに猶予期間

が適用されなくなっており、現在は通常の運用モードで動作していることを示します。

12.4.5 結論

前の手順をすべて完了したら、エクスポートされたNFSを2つのNFS Ganeshaサーバのいずれかから

マウントして、NFSの通常の操作を実行できます。

このサンプル設定では、2つのNFS Ganeshaサーバの一方がダウンした場合、5分以内にユーザが手

動で再起動することを想定しています。5分を過ぎると、NFS Ganeshaクライアントが保持していたセッ

ションと、そのセッションに関連付けられているすべての状態がMetadata Serverによってキャンセルさ

れる場合があります。クラスタの残りが猶予期間に入る前にセッションの機能がキャンセルされた場合、

サーバのクライアントは、その状態のすべてを回復できない可能性があります。

12.5 詳細情報詳細については、『管理ガイド』、第21章「NFS Ganesha: NFS経由でのCephデータのエクスポー

ト」を参照してください。

139 NFS Ganeshaサービスの再起動 SES 6

IV SUSE CaaS Platform 4上でのクラスタの展開(技術プレビュー)

13 SUSE CaaS Platform 4 Kubernetesクラスタ上のSUSE EnterpriseStorage 6 141

13 SUSE CaaS Platform 4 Kubernetesクラスタ上のSUSE Enterprise Storage 6

警告: 技術プレビューSUSE CaaS Platform上でコンテナ化されたCephクラスタを実行することは、技術プレビュー

です。Kubernetesの運用クラスタには展開しないでください。

この章では、SUSE CaaS Platform 4 Kubernetesクラスタ上でコンテナ化されたSUSE

Enterprise Storage 6を展開する方法について説明します。

13.1 注意事項展開を開始する前に、次の点を考慮してください。

KubernetesでCephを実行するため、SUSE Enterprise Storage 6はRook (https://

rook.io/ )と呼ばれるアップストリームプロジェクトを使用します。

設定によっては、Rookは、Kubernetesクラスタ内にあるすべてのノード上の未使用ディスクを

「すべて」使用する場合があります。

セットアップには特権付きのコンテナが必要です。

13.2 前提条件展開を開始する前に、以下が必要です。

稼働中のSUSE CaaS Platform 4クラスタ。

SUSE CaaS Platform 4のワーカノードと、Cephクラスタ用のストレージとして追加された多数

の追加ディスク。

13.3 Rookマニフェストの取得Rookオーケストレータは、「マニフェスト」と呼ばれるYAML形式の設定ファイルを使用します。必要な

マニフェストは、 rook-k8s-yaml のRPMパッケージに含まれています。次のコマンドを実行して、これ

をインストールします。

141 注意事項 SES 6

https://rook.io/

https://rook.io/

root # zypper install rook-k8s-yaml

13.4 インストールRook-Cephには、2つのメインコンポーネントが含まれます。Kubernetesによって実行され、Ceph

クラスタを作成できるようにする「オペレータ」と、オペレータによって作成され、部分的に管理される

Ceph「クラスタ」そのものです。

13.4.1 設定

13.4.1.1 グローバル設定

このセットアップで使用されるマニフェストは、RookおよびCephのすべてのコンポーネントを「rook-

ceph」ネームスペースにインストールします。これを変更する必要がある場合は、Kubernetesマニフェ

ストでこのネームスペースへのすべての参照を適切に変更します。

使用するRookの機能に応じて、 common.yamlの「Pod Security Policy」の設定を変更し、Rookの

セキュリティ要件を制限します。マニフェストファイルのコメントに従います。

13.4.1.2 オペレータの設定

マニフェスト operator.yamlは、Rookオペレータを設定します。通常、変更する必要はありません。マ

ニフェストファイルのコメントに従って、詳細を確認してください。

13.4.1.3 Cephクラスタの設定

マニフェスト cluster.yamlは、Kubernetesで実行される実際のCephクラスタを設定します。使

用可能なすべてのオプションの詳しい説明については、https://rook.io/docs/rook/v1.0/ceph-

cluster-crd.html にあるアップストリームのRookドキュメントを参照してください。

デフォルトでは、Rookは、 node-role.kubernetes.io/master:NoScheduleが指定されていな

いすべてのノードを使用するように設定され、設定されている配置設定に従います(https://rook.io/

docs/rook/v1.0/ceph-cluster-crd.html#placement-configuration-settings を参照してくださ

い)。次の例では、このような動作を無効にし、nodesセクションで明示的に一覧にされているノードのみ

を使用します。

storage:

142 インストール SES 6

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-configuration-settings

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-configuration-settings

useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2

注記デフォルトでは、Rookは、各ノード上にある空きディスクと空のディスクをすべて使用し

て、Cephストレージとして使うように設定されます。

13.4.1.4 マニュアル

https://rook.github.io/docs/rook/master/ceph-storage.html にあるRook-Cephアップ

ストリームマニュアルには、より詳細な展開を設定するための詳細情報が記載されています。この

マニュアルをリファレンスとして使用してRook-Cephの基礎を理解してから、詳細設定を行ってく

ださい。

SUSE CaaS Platform製品の詳細については、https://www.suse.com/documentation/

suse-caasp を参照してください。

13.4.2 Rookオペレータの作成次のコマンドを実行して、SUSE CaaS Platformマスタノードに、Rook-Cephの共通コンポーネン

ト、CSIの役割、およびRook-Cephオペレータをインストールします。

root # kubectl apply -f common.yaml -f operator.yaml

common.yamlは、「rook-ceph」ネームスペース、KubernetesがCephオブジェクト(「CephCluster」

など)を認識できるようにするためのCeph CRD (カスタムリソース定義) (https://kubernetes.io/

docs/concepts/extend-kubernetes/api-extension/custom-resources/ を参照)、およびRook

がクラスタ固有のリソースを管理できるようにするために必要なおよびRBACの役割とPod Security

Policy (https://kubernetes.io/docs/concepts/policy/pod-security-policy/ を参照)を作成し

ます。

ヒント: hostNetworkとhostPortsの使用クラスタリソース定義で hostNetwork: trueを使用する場合、 hostNetworkを使用できるよ

うにする必要があります。また、 PodSecurityPolicyで hostPortsを使用できるようにする必

要もあります。

143 Rookオペレータの作成 SES 6

https://rook.github.io/docs/rook/master/ceph-storage.html

https://www.suse.com/documentation/suse-caasp

https://www.suse.com/documentation/suse-caasp

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

SUSE CaaS Platformマスタノードで kubectl get pods -n rook-cephを実行して、インストール

を確認します。次に例を示します。

root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.4.3 Cephクラスタの作成

ニーズに合わせて cluster.yamlを変更したら、Cephクラスタを作成できます。SUSE CaaS

Platformマスタノードで次のコマンドを実行します。

root # kubectl apply -f cluster.yaml

「rook-ceph」ネームスペースを確認して、Cephクラスタが作成されていること確認しま

す。 cluster.yamlマニフェストで設定した数のCeph Manager (デフォルトは3つ)、1つのCeph

Monitor、および空きディスクと同じ数のCeph OSDが表示されます。

ヒント: 一時的なOSDポッドCephクラスタのブートストラップ中に、 rook-ceph-osd-prepare-NODE-NAMEという名前の

複数のポッドがしばらく実行された後、「Completed」のステータスで終了するのを確認できま

す。名前からわかるように、これらのポッドはCeph OSDをプロビジョニングします。終了後にロ

グを検査できるように、これらのログは削除されずに残されます。次に例を示します。

root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22hrook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22h

144 Cephクラスタの作成 SES 6

rook-discover-tztz4 1/1 Running 0 22h

13.5 Kubernetesワークロード用ストレージとしてのRookの使用Rookでは、3つの異なるタイプのストレージを使用できます。

オブジェクトストレージ

オブジェクトストレージは、S3 APIをストレージクラスタに公開し、アプリケーションがデータを配

置および取得できるようにします。詳細な説明については、https://rook.io/docs/rook/v1.0/

ceph-object.html を参照してください。

共有ファイルシステム

共有ファイルシステムは、複数のポッドから読み込み/書き込み許可を使用してマウントできます。

これは、共有ファイルシステムを使用してクラスタ化されるアプリケーションで役立ちます。詳細な

説明については、https://rook.io/docs/rook/v1.0/ceph-filesystem.html を参照してくだ

さい。

ブロックストレージ

ブロックストレージでは、1つのポッドにストレージをマウントできます。詳細な説明について

は、https://rook.io/docs/rook/v1.0/ceph-block.html を参照してください。

13.6 RookのアンインストールRookをアンインストールするには、次の手順に従います。

1. Rookストレージを使用しているすべてのKubernetesアプリケーションを削除します。

2. 13.5項「Kubernetesワークロード用ストレージとしてのRookの使用」に従って、作成したオブ

ジェクト、ファイル、およびブロックストレージのアーティファクトをすべて削除します。

3. Cephクラスタ、オペレータ、および関連するリソースを削除します。

root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml

4. ホスト上のデータを削除します。

145 Kubernetesワークロード用ストレージとしてのRookの使用 SES 6

https://rook.io/docs/rook/v1.0/ceph-object.html

https://rook.io/docs/rook/v1.0/ceph-object.html

https://rook.io/docs/rook/v1.0/ceph-filesystem.html

https://rook.io/docs/rook/v1.0/ceph-block.html

root # rm -rf /var/lib/rook

5. 必要に応じて、Rookによって使用されていたディスクを消去します。詳細については、https://

rook.io/docs/rook/master/ceph-teardown.html を参照してください。

146 Rookのアンインストール SES 6

https://rook.io/docs/rook/master/ceph-teardown.html

https://rook.io/docs/rook/master/ceph-teardown.html

A アップストリーム「Nautilus」ポイントリリースに基づくCeph保守更新

SUSE Enterprise Storage 6のいくつかの主要パッケージは、CephのNautilusリリースシリーズに

基づいています。Cephプロジェクト(https://github.com/ceph/ceph )がNautilusシリーズの新

しいポイントリリースを公開した場合、SUSE Enterprise Storage 6は、アップストリームの最新のバグ

修正や機能のバックポートのメリットを得られるように更新されます。

この章には、製品に組み込み済みか、組み込みが予定されている各アップストリームポイントリリースに

含まれる重要な変更点についての概要が記載されています。

Nautilus 14.2.4ポイントリリースこのポイントリリースでは、14.2.3ポイントリリースで見つかった重大なリグレッションが修正され

ます。SUSEは14.2.3に基づくバージョンを出荷していないため、このバグはSUSE Enterprise

Storageのお客様には影響しませんでした。

Nautilus 14.2.3ポイントリリース

サービス拒否の脆弱性により、認証されていないCeph Object Gatewayクライアントが、キャッ

チされない例外によるクラッシュをトリガする可能性がありました。この脆弱性を修正しました。

NautilusベースのlibrbdクライアントでJewelクラスタ上のイメージを開くことができるようになり

ました。

Object Gateway num_rados_handlesが削除されました。1より大き

い num_rados_handlesの値を使用している場合に、同じ調整動作を実現するには、現在

の objecter_inflight_opsパラメータと objecter_inflight_op_bytesパラメータに古

い num_rados_handlesを掛けます。

このリリースにより、Messenger v2プロトコルのセキュアモードは実験用ではなくなりました。この

モードは、モニター接続の優先モードになりました。

osd_deep_scrub_large_omap_object_key_thresholdの値を下げ、大量のomapキーが含

まれるオブジェクトをより簡単に検出できるようにしました。

CephダッシュボードがPrometheus通知の無音化をサポートしました。

147 Nautilus 14.2.4ポイントリリース SES 6

https://github.com/ceph/ceph

Nautilus 14.2.2ポイントリリース

no{up,down,in,out}関連のコマンドが刷新されました。 no{up,down,in,out}フラグを設定

する方法は2つあります。古いコマンドは次のとおりです。

ceph osd [un]set FLAG

これは、クラスタ全体にフラグを設定します。新しいコマンドは次のとおりです。

ceph osd [un]set-group FLAGS WHO

これは、クラッシュノードまたはデバイスクラスの粒度でバッチでフラグを設定します。

古いバージョンのObject Gatewayでは、バケットのリシャーディング後に、期限切れの古いオブ

ジェクトが残ることがありました。 radosgw-adminに、このようなオブジェクトを管理できるサブコ

マンドが2つ導入されました。一方のサブコマンドは、このようなオブジェクトを一覧にし、他方のサ

ブコマンドはこれらを削除します。

以前のNautilusリリース(14.2.1および14.2.0)には、アップグレードされたクラスタ

(元々、Nautilus以前に導入されたクラスタ)に単一の新しいNautilus BlueStore OSDを導

入すると、 ceph dfによってレポートされるプール使用率統計情報が壊れるという問題があ

りました。すべてのOSDを再プロビジョニングまたは更新するまで( ceph-bluestore-tool

repairを使用)、プール統計情報には、実際の値より小さい値が表示されます。これが14.2.2で

解決され、クラスタはより正確なプールごとの統計を使用するように切り替わります。ただし、「す

べて」のOSDが14.2.2以降であること、ブロックストレージであること、かつNautilusより前に作

成されている場合は修復機能を使用して更新されていること、という条件があります。

mon_crush_min_required_versionのデフォルト値が fireflyから hammerに変更されまし

た。つまり、CRUSH調整可能パラメータがHammerより古い場合、クラスタによってヘルス警告

が発行されます。一般的には、Hammer調整可能パラメータに切り替わることでリバランスされる

データの量は、わずかです(ただし、ゼロではありません)。

可能な場合は、許可されている最も古いクライアントを hammer以降に設定することをお勧めしま

す。現在許可されている最も古いクライアントを表示するには、次のコマンドを実行します。

cephadm@adm > ceph osd dump | grep min_compat_client

現在の値が hammerより古い場合は、次のコマンドを実行して、現在クラスタに接続しているクラ

イアントの中にHammerより古いものがないことを確認し、この変更を行っても安全かどうかを判

断してください。

cephadm@adm > ceph features


新しい straw2 CRUSHバケットタイプがHammerに導入されました。すべてのクライアントが

Hammer以降であることを確認したら、バランサの crush-compatモードを含む、 straw2バケッ

トでのみサポートされる新機能を使用できます(『管理ガイド』、第10章「Ceph Managerモジュー

ル」、10.1項「バランサ」)。

パッチの詳細については、https://download.suse.com/Download?

buildid=D38A7mekBz4~ を参照してください。

Nautilus 14.2.1ポイントリリースこれは、元のNautilusリリース(14.2.0)に続く最初のポイントリリースでした。SUSE Enterprise

Storage 6の元の(「一般提供」または「GA」)バージョンは、このポイントリリースに基づいていました。


https://download.suse.com/Download?buildid=D38A7mekBz4~

https://download.suse.com/Download?buildid=D38A7mekBz4~

用語集

全般

CRUSH、CRUSHマップ「Controlled Replication Under Scalable Hashing」: データの保存場所を計算することに

よって、データの保存と取得の方法を決定するアルゴリズム。CRUSHは、クラスタ全体に均等に分

散したデータを擬似ランダムにOSDで保存および取得するために、クラスタのマップを必要としま

す。

Monitorノード、MONクラスタの状態のマップ(Monitorマップを含む)またはOSDマップを維持するクラスタノード。

OSDコンテキストによって異なり、「オブジェクトストレージデバイス」または「オブジェクトストレージデー

モン」。 ceph-osdデーモンは、ローカルファイルシステムにオブジェクトを保存し、ネットワーク経由

でそれらにアクセスできるようにするCephのコンポーネントです。

OSDノードデータの保存、データレプリケーションの処理、回復、バックフィル、およびリバランスを実行し、他の

Ceph OSDデーモンを確認することによってCeph Monitorにモニタリング情報を提供するクラス

タノード。

PG配置グループ: 「プール」を細分化したもので、パフォーマンスを調整するために使用します。

ノードCephクラスタ内の1つのマシンまたはサーバ。

バケット他のノードを物理的な場所の階層に集約するポイント。

重要: S3のバケットと混同しないS3の「バケット」または「コンテナ」は、オブジェクトを格納するための「フォルダ」を意味する

別の用語を表します。

150 SES 6

プールディスクイメージなどのオブジェクトを保存するための論理パーティション。

ルーティングツリー受信者が実行できるさまざまなルートを示す図に付けられる用語。

ルールセットプールのデータ配置を決定するためのルール。

管理ノードOSDノードにCephを展開するために ceph-deployユーティリティを実行するノード。

Ceph固有の用語

AlertmanagerPrometheusサーバによって送信されるアラートを処理し、エンドユーザに通知する単一のバイナ

リ。

Ceph Storage Clusterユーザのデータを保存するストレージソフトウェアのコアセット。1つのセットは複数のCeph

Monitorと複数のOSDで構成されます。

「Ceph Object Store」とも呼ばれます。

Grafanaデータベース分析および監視ソリューション。

Prometheusシステム監視およびアラートツールキット。

Object Gateway固有の用語

Object GatewayCeph Object Store用のS3/Swiftゲートウェイコンポーネント。

151 SES 6

アーカイブ同期モジュールS3オブジェクトのバージョン履歴を保持するためのObject Gatewayゾーンを作成できるモジュー

ル。

152 SES 6

B マニュアルの更新

この章では、SUSE Enterprise Storage 5の最新の保守更新のリリース以降に、このドキュメン

トの内容に加えられた変更点について説明します。旧バージョンに適用されるクラスタ展開関連の

変更点については、https://www.suse.com/documentation/suse-enterprise-storage-5/

book_storage_deployment/data/ap_deploy_docupdate.html を参照してください。

このドキュメントは次の日付に更新されました。

B.1項「SUSE Enterprise Storage 6ドキュメントの保守更新」

B.2項「2019年6月(SUSE Enterprise Storage 6のリリース)」

B.1 SUSE Enterprise Storage 6ドキュメントの保守更新全般的な更新

6.8項「ノード単位のアップグレード — 基本的な手順」で、ローカルな変更が失われないよ

うにするため、 rpmconfigcheckの実行を推奨しました(https://jira.suse.com/browse/

SES-348 )。

『管理ガイド』、第15章「LVMキャッシュによるパフォーマンスの向上」を追加しました(https://

jira.suse.com/browse/SES-269 )。

第13章「SUSE CaaS Platform 4 Kubernetesクラスタ上のSUSE Enterprise Storage 6」を

追加しました(https://jira.suse.com/browse/SES-720 )。

バグ修正

6.9項「管理ノードのアップグレード」に、アップグレード中にクラスタノードのステータスを

監視することに関するヒントを追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=1154568 )。

6.8.2項「SUSE Distribution Migration Systemを使用したノードのアップグレード」を追加しま

した(https://bugzilla.suse.com/show_bug.cgi?id=1154438 )。

アップグレードに関する章第6章「古いリリースからのアップグレード」が連続するようにしました

(https://bugzilla.suse.com/show_bug.cgi?id=1144709 )。

Ceph 14.2.4の変更ログエントリを追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=1151881 )。

153 SUSE Enterprise Storage 6ドキュメントの保守更新 SES 6

https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_deployment/data/ap_deploy_docupdate.html

https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_deployment/data/ap_deploy_docupdate.html

https://jira.suse.com/browse/SES-348





https://bugzilla.suse.com/show_bug.cgi?id=1154568






第12章「NFS Ganeshaのインストール」の例で、プール名「cephfs_metadata」を統合しました


5.5.2.1項「仕様」を更新して、より現実的な値を含めました(https://bugzilla.suse.com/

show_bug.cgi?id=1148216 )。

6.8.1項「インストーラDVDを使用したノードの手動アップグレード」で、顧客は主にGUIを

使用しているため、「Module-Desktop」に新しいリポジトリを2つ追加しました(https://

bugzilla.suse.com/show_bug.cgi?id=1144897 )。

deepsea-cli は deepsea の依存関係ではないことを、5.4項「DeepSea CLI」で説明しまし

た(https://bugzilla.suse.com/show_bug.cgi?id=1143602 )。

6.1項「アップグレード前に考慮すべき点」に、 ntpdを chronydに移行するためのヒントを追加し

ました(https://bugzilla.suse.com/show_bug.cgi?id=1135185 )。

『管理ガイド』、第2章「Saltクラスタの管理」、2.15項「調整済みプロファイルの無効化」を追加し


6.16.3項「OSDの展開」では、OSDノード全体の移行を検討します(https://


6.1項「アップグレード前に考慮すべき点」に、MDS名の移行に関するポイントを追加しました


B.2 2019年6月(SUSE Enterprise Storage 6のリリース)全般的な更新

5.5.2項「DriveGroups」を追加しました(jsc#SES-548)。

第6章「古いリリースからのアップグレード」を書き換えました(jsc#SES-88)。

7.2.1項「Cephクラスタ展開のためのIPv6の有効化」を追加しました(jsc#SES-409)。

ブロックストレージをデフォルトのストレージバックエンドにしました(Fate#325658)。

外部オンラインドキュメントへの参照をすべて削除し、関連する内容で置き換えました

(Fate#320121)。

バグ修正

6.1項「アップグレード前に考慮すべき点」に、アップグレード時におけるAppArmorに関する情

報を追加しました (https://bugzilla.suse.com/show_bug.cgi?id=1137945 )。

154 2019年6月(SUSE Enterprise Storage 6のリリース) SES 6













6.1項「アップグレード前に考慮すべき点」に、オンラインアップグレードをサポートしない

CDTBクラスタに関する情報を追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=1129108 )。

12.3項「高可用性のアクティブ-パッシブ設定」に、高可用性セットアップでのCephサービス

のコロケーションに関する情報を追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=1136871 )。

6.8項「ノード単位のアップグレード — 基本的な手順」に、孤立パッケージに関するヒントを追加

しました(https://bugzilla.suse.com/show_bug.cgi?id=1136624 )。

ヒント: OSDプロファイルを定義せずにモニタノードを展開で、 profile-*を role-storageで更

新しました(https://bugzilla.suse.com/show_bug.cgi?id=1138181 )。

6.16項「プロファイルベースの展開からDriveGroupsへのマイグレーション」を追加しました


6.11項「Metadata Serverのアップグレード」を追加しました(https://bugzilla.suse.com/


6.1項「アップグレード前に考慮すべき点」で、MDSクラスタを縮小する必要があります(https://


設定ファイルを /srv/pillar/ceph/stack/global.ymlに変更しました(https://


『管理ガイド』、第20章「Sambaを介したCephデータのエクスポート」のさまざまな部分を更新し


5.3項「クラスタの展開」で master_minion.slsを削除しました(https://bugzilla.suse.com/


パッケージ deepsea-cli について5.4項「DeepSea CLI」で説明しました(https://


155 2019年6月(SUSE Enterprise Storage 6のリリース) SES 6



















導入ガイド - suse enterprise storage 6€¦ · 目次 このガイドについて x i suse...

Documents

導入ガイド - suse enterprise storage 6€¦ · 目次このガイドについて x i suse...