1 SESとCeph #
SUSE Enterprise Storageは、スケーラビリティ、信頼性、およびパフォーマンスを目的として設計された、Cephテクノロジに基づく分散ストレージシステムです。Cephクラスタは、Ethernetなどの一般的なネットワーク内にあるコモディティサーバで実行できます。クラスタは、数千台のサーバ(以降、ノードと呼びます)とペタバイトの域にまで容易に拡張できます。データを保存および取得するためのアロケーションテーブルを持つ従来のシステムとは異なり、Cephは決定的アルゴリズムを使用してデータの記憶域を割り当て、集中化された情報構造を持ちません。Cephでは、Storage Cluster内でのハードウェアの追加や削除は、例外ではなく標準の動作であると想定されています。Cephクラスタは、データの分散と再分散、データの複製、障害検出、回復などの管理タスクを自動化します。Cephは自己修復機能と自己管理機能の両方を備えているため、管理と予算のオーバーヘッドが削減されます。
この章では、SUSE Enterprise Storage 7.1の大まかな概要と、最も重要なコンポーネントについて簡単に説明します。
1.1 Cephの特徴 #
Ceph環境には次のような特徴があります。
- 拡張性
Cephは数千台のノードにまで拡張でき、ペタバイトの域のストレージを管理できます。
- コモディティハードウェア
Cephクラスタを実行するのに特別なハードウェアは必要ありません。詳細については、第2章 「ハードウェア要件と推奨事項」を参照してください。
- 自己管理
Cephクラスタは自己管理型です。ノードが追加または削除された場合、あるいはノードに障害が発生した場合、クラスタは自動的にデータを再分散します。過負荷状態のディスクを認識する機能もあります。
- SPOF (Single Point of Failure)を排除
クラスタ内のノードが重要な情報を単独で保存することはありません。冗長性の数は設定が可能です。
- オープンソースのソフトウェア
Cephは、特定のハードウェアやベンダーとは無関係のオープンソースソフトウェアソリューションです。
1.2 Cephのコアコンポーネント #
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
RADOS Block Device (RBD)には他のブロックデバイスと同じようにアクセスできます。たとえば、仮想化を行う場合、RBDと
libvirtを組み合わせて使用できます。- CephFS
Ceph File SystemはPOSIX互換のファイルシステムです。
libradoslibradosは、Storage Clusterを直接操作できるアプリケーションを作成するためのライブラリで、さまざまなプログラミング言語で使用できます。
Object GatewayとRBDはlibradosを使用するのに対し、CephFSは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つのラック列に電力を供給している場合は、障害ドメインを列に設定できます。配電ユニットに障害が発生しても、引き続き他の列で複製されたデータを利用できます。
1.2.3 Cephのノードとデーモン #
Cephでは、ノードとはクラスタを形成しているサーバです。ノードでは複数の種類のデーモンを実行できます。各ノードで実行するデーモンは1種類だけにすることをお勧めします。ただし、Ceph Managerデーモンは例外で、Ceph Monitorと一緒に配置できます。各クラスタには、少なくともCeph Monitor、Ceph Manager、およびCeph OSDデーモンが必要です。
- 管理ノード
「管理ノード」とは、コマンドを実行してクラスタを管理するCephクラスタノードを指します。管理ノードはCephクラスタの中心となる場所です。これは、Salt Minionサービスに対してクエリと命令を行って他のクラスタノードを管理する役割があるためです。
- 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はクラスタ全体から状態情報を収集します。Ceph ManagerデーモンはCeph Monitorデーモンと共に動作します。追加のモニタリング機能を提供し、外部のモニタリングシステムや管理システムとのインタフェースとして機能します。これには、他のサービスも含まれます。たとえば、CephダッシュボードWeb UIはCeph Managerと同じノードで実行されます。
Ceph Managerには、動作確認以外の追加設定は必要ありません。
- Ceph OSD
「Ceph OSD」は、「オブジェクトストレージデバイス」を処理するデーモンです。OSDは、物理ストレージユニットまたは論理ストレージユニット(ハードディスクまたはパーティション)になります。オブジェクトストレージデバイスは、物理ディスク/パーティションにも、論理ボリュームにもできます。このデーモンはほかにも、データのレプリケーションや、ノードが追加または削除された場合のリバランスも処理します。
Ceph OSDデーモンはモニターデーモンと通信して、他のOSDデーモンの状態をモニターデーモンに提供します。
CephFS、Object Gateway、NFS Ganesha、またはiSCSI Gatewayを使用するには、追加のノードが必要です。
- MDS (メタデータサーバ)
CephFSのメタデータは自身のRADOSプールに保存されます(1.3.1項 「プール」を参照してください)。メタデータサーバはスマートなメタデータのキャッシュ層として機能し、必要に応じてアクセスをシリアル化します。これにより、明示的な同期を取ることなく多数のクライアントからの同時アクセスが可能となります。
- 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 Cephのストレージ構造 #
1.3.1 プール #
Cephクラスタに保存されるオブジェクトは「プール」に配置されます。プールは、外部環境に対してはクラスタの論理パーティションを表します。各プールに対して一連のルールを定義できます。たとえば、各オブジェクトのレプリケーションがいくつ存在する必要があるかなどを定義できます。プールの標準設定を「複製プール」と呼びます。
通常、プールにはオブジェクトが含まれていますが、RAID 5と同様の動作をするように設定することもできます。この設定の場合、オブジェクトは追加のコーディングチャンクと共にチャンクで保存されます。コーディングチャンクには冗長な情報が含まれます。データとコーディングチャンクの数は管理者が定義できます。この設定の場合、プールは「イレージャコーディングプール(ECプール)」と呼ばれます。
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」または「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に複製され、レプリケーションレベルが復元されます。
新しいOSDを持つ新しいノードがクラスタに追加されると、クラスタマップが変更されます。それに従って、CRUSH機能はオブジェクトに対して別の場所を返します。新しい場所を受け取ったオブジェクトは、別の場所に移動されます。このプロセスにより、すべてのOSDがバランス良く使用されます。
1.4 BlueStore #
SES 5から、BlueStoreがCephの新しいデフォルトストレージバックエンドになりました。BlueStoreはFileStoreよりもパフォーマンスが高く、データの完全なチェックサムや組み込みの圧縮機能を備えています。
BlueStoreは、1つ、2つ、または3つのいずれかのストレージデバイスを管理します。最もシンプルなケースでは、BlueStoreは1つのプライマリストレージデバイスを使用します。通常、ストレージデバイスは、次の2つの部分にパーティション分割されます。
BlueFSという名前の小容量のパーティション。RocksDBで必要な、ファイルシステムに似た機能を実装します。
通常、デバイスの残りの部分は、その部分を占有する大容量のパーティションになります。これはBlueStoreによって直接管理され、実際のデータがすべて含まれます。通常、このプライマリデバイスは、データディレクトリ内ではブロックシンボリックリンクで識別されます。
次のように、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デバイスがいっぱいになると、メタデータがプライマリデバイスにあふれ、OSDのパフォーマンスが大きく低下します。
ceph daemon osd.ID perf dumpコマンドを使用して、WAL/DBパーティションがいっぱいであふれそうかどうかを調べることができます。slow_used_bytesの値に、あふれているデータの量が表示されます。
cephuser@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,1.5 追加情報 #
コミュニティプロジェクトとして、Cephには、独自の広範なオンラインヘルプがあります。このマニュアルに記載されていないトピックについては、https://docs.ceph.com/en/pacific/を参照してください。
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配布パッケージベンダーによってサポートされます。