Cephの基本コンポーネントは「RADOS (Reliable Autonomic Distributed Object Store) 」と呼ばれます。これは、クラスタに保存されるデータの管理を受け持ちます。通常、Ceph内のデータはオブジェクトとして保存されています。各オブジェクトはIDとデータで構成されます。

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

Object GatewayとRBDはlibradosを使用するのに対し、CephFSはRADOSと直接対話します。図1.1「Ceph Object Storeのインタフェース」を参照してください。

図 1.1: Ceph Object Storeのインタフェース #

 

Cephクラスタの中核を成すのは「CRUSH」アルゴリズムです。CRUSHは「Controlled Replication Under Scalable Hashing」の略語です。CRUSHはストレージの割り当てを扱う機能で、指定が必要なパラメータは比較的少なくなっています。つまり、オブジェクトの保存位置を計算するのに必要な情報はごくわずかです。そのパラメータは、ヘルス状態を含むクラスタの現在のマップ、管理者定義の配置ルール、および保存または取得する必要があるオブジェクトの名前です。この情報により、Cephクラスタ内のすべてのノードは、オブジェクトとそのレプリカが保存されている場所を計算できます。このため、データの読み書きが非常に効率化されます。CRUSHは、データをクラスタ内のすべてのノードに均等に分散しようとします。

「CRUSHマップ」には、クラスタにオブジェクトを保存するための、すべてのストレージノードと管理者定義の配置ルールが記述されています。CRUSHマップは階層構造を定義し、その階層構造は通常、クラスタの物理構造に対応します。たとえば、データが含まれるディスクがホストにあり、ホストがラックに格納されているとします。さらに、ラックは複数の列に収容されていて、ラック列はデータセンターにあるとします。この構造を使用して「障害ドメイン」を定義できます。Cephは、それに従ってレプリケーションが特定の障害ドメインの異なるブランチに保存されるようにします。

障害ドメインがラックに設定されている場合、オブジェクトのレプリケーションは異なるラックに分散されます。これによって、ラック内のスイッチの障害によって発生する停止を緩和できます。1台の配電ユニットで1つのラック列に電力を供給している場合は、障害ドメインを列に設定できます。配電ユニットに障害が発生しても、引き続き他の列で複製されたデータを利用できます。

Cephでは、ノードとはクラスタを形成しているサーバです。ノードでは複数の種類のデーモンを実行できます。各ノードで実行するデーモンは1種類だけにすることをお勧めします。ただし、Ceph Managerデーモンは例外で、Ceph Monitorと一緒に配置できます。各クラスタには、少なくともCeph Monitor、Ceph Manager、およびCeph OSDデーモンが必要です。

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

Cephクラスタに保存されるオブジェクトは「プール」に配置されます。プールは、外部環境に対してはクラスタの論理パーティションを表します。各プールに対して一連のルールを定義できます。たとえば、各オブジェクトのレプリケーションがいくつ存在する必要があるかなどを定義できます。プールの標準設定を「複製プール」と呼びます。

通常、プールにはオブジェクトが含まれていますが、RAID 5と同様の動作をするように設定することもできます。この設定の場合、オブジェクトは追加のコーディングチャンクと共にチャンクで保存されます。コーディングチャンクには冗長な情報が含まれます。データとコーディングチャンクの数は管理者が定義できます。この設定の場合、プールは「イレージャコーディングプール(ECプール)」と呼ばれます。

「配置グループ」(PG)は、プール内でデータを分散するために使用されます。プールの作成時に、一定数の配置グループが設定されます。配置グループは、オブジェクトをグループ化するために内部的に使用され、Cephクラスタのパフォーマンスにおける重要な要因です。オブジェクトのPGはオブジェクトの名前によって決定されます。

このセクションでは、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に複製され、レプリケーションレベルが復元されます。

図 1.2: 小規模なCephの例 #

 

新しいOSDを持つ新しいノードがクラスタに追加されると、クラスタマップが変更されます。それに従って、CRUSH機能はオブジェクトに対して別の場所を返します。新しい場所を受け取ったオブジェクトは、別の場所に移動されます。このプロセスにより、すべてのOSDがバランス良く使用されます。

十分に要件を満たせるような帯域幅を備えた、フォールトトレラントな単一のネットワークをお勧めします。Cephパブリックネットワーク環境では、802.3ad (LACP)を使用してボンディングされた2つの25GbE (またはそれ以上)のネットワークインターフェイスをお勧めします。この環境がCephの最小セットアップとみなされます。クラスタネットワークを使用する場合、25GbEのネットワークインターフェイスを4つボンディングすることをお勧めします。2つ以上のネットワークインターフェイスをボンディングすることで、リンクアグリゲーションによりスループットが改善されます。さらに、リンクとスイッチに冗長性が与えられるため、耐障害性と保守性が向上します。

VLANを作成することで、ボンディングした機器を通過する異なるタイプのトラフィックを分離することもできます。たとえば、1つはパブリックネットワーク用、もう1つはクラスタネットワーク用として、計2つのVLANインターフェイスを提供するようにボンディングを設定できます。しかしながら、これはCephネットワークを構成する際の必須事項ではありません。ネットワークインターフェイスのボンディングの詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bondingを参照してください。

耐障害性はコンポーネントを障害ドメインに隔離することで強化できます。ネットワークの耐障害性を改善する目的で、別々のネットワークインターフェイスカード(NIC)2枚を1つのインターフェイスにボンディングすると、単一のNICの障害に対する保護が提供されます。同様に、2つのスイッチをボンディングすると、単一のスイッチの障害に対する保護が提供されます。必要なレベルの耐障害性を構築するために、ネットワーク機器のベンダーに相談することをお勧めします。

重要: 管理ネットワークはサポート対象外

管理ネットワークのセットアップ(たとえば、分離されたSSH、Salt、またはDNSのネットワーク形成を可能とするもの)の追加はテストされておらず、サポート対象外です。

ヒント: DHCP経由で設定されたノード

ストレージノードがDHCP経由で設定されている場合、さまざまCephデーモンが起動する前にネットワークを正しく設定するのにデフォルトのタイムアウトでは十分でないことがあります。この場合、CephのMONとOSDを正常に起動できません(systemctl status ceph\*を実行すると「unable to bind」エラーになります)。この問題を回避するには、ストレージクラスタの各ノードでDHCPクライアントのタイムアウト時間を少なくとも30秒まで延ばすことをお勧めします。このためには、各ノードで以下の設定を変更します。

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

DHCLIENT_WAIT_AT_BOOT="30"

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

WAIT_FOR_INTERFACES="60"

2.1.1.2 異なるサブネット上のモニタノード #

 

モニタノードが複数のサブネット上に存在する場合(たとえば、別の部屋に配置されていたり、別のスイッチによってサービスを提供されていたりする場合)、CIDR表記でパブリックネットワークアドレスを指定する必要があります。

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

以下に例を示します。

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

警告

このセクションで説明するように、パブリックネットワーク(またはクラスタネットワーク)用に複数のネットワークセグメントを指定する場合、これらのサブネットはいずれも他のすべてのサブネットにルーティングできる必要があります。さもなければ、異なるネットワークセグメント上に存在するMONなどのCephデーモンが通信できず、クラスタが分割されてしまいます。また、ファイアウォールを使用している場合、必要に応じて、iptablesに各IPアドレスやサブネットを含め、すべてのノードでこれらのアドレスに対してポートを開放したかを確認してください。

最小限の運用クラスタは、次のような構成です。

詳細な構成は以下の通りです。

図 2.2: 最小クラスタ構成 #

 

クラスタを拡張した場合、耐障害性を高めるため、Ceph Monitor、メタデータサーバ、ゲートウェイを別々のノードに再配置することをお勧めします。

マルチパスハードウェアを使用したい場合、設定ファイルのdevicesセクションでLVMがmultipath_component_detection = 1を認識するようにしてください。この設定は、lvm configコマンドで確認できます。

もしくは、LVMのフィルタ設定により、LVMがデバイスのmpathコンポーネントをフィルタするようにしてください。これはホスト固有です。

注記

この方法はお勧めしません。multipath_component_detection = 1を設定できない場合にのみ検討する必要があります。

マルチパス設定の詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvmを参照してください。

OSD上で実行する必要があるディスク領域には2つのタイプがあります。WAL/DBデバイス用の領域と、保存データ用のプライマリ領域です。WAL/DBの最小値(デフォルト値)は6GBです。データ用の最小領域は5GBです。これは、5GB未満のパーティションには自動的に重み0が割り当てられるためです。

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

SSD (ソリッドステートドライブ)には可動部品がありません。これは、ランダムアクセス時間と読み込みレイテンシを短縮すると同時に、データスループットを加速します。SSDの1MBあたりの価格は回転型ハードディスクの価格より大幅に高いため、SSDは小容量のストレージにのみ適しています。

WAL/DBパーティションをSSDに保存し、オブジェクトデータは別個のハードディスクに保存することで、OSDのパフォーマンスを大幅に向上させることができます。

ヒント: 複数のWAL/DBパーティションでSSDを共有

WAL/DBパーティションは比較的小さい領域しか占有しないため、1つのSSDディスクを複数のWAL/DBパーティションで共有できます。WAL/DBパーティションを増やすほど、SSDディスクのパフォーマンスが低下することに注意してください。同じSSDディスクでWAL/DBパーティションを7つ以上共有することはお勧めしません。NVMeディスクの場合、13個以上の共有はお勧めしません。

1台のサーバで、そのサーバで使用できる数だけのディスクを使用できます。サーバあたりのディスク数を計画する際には、考慮すべき点がいくつかあります。

SUSE ManagerとSUSE Enterprise Storageは統合されていません。そのため、現在のところSUSE ManagerでSESクラスタを管理することはできません。

configをパスやサブコマンドを使わずに実行する場合、インタラクティブなceph-saltceph-saltシェルを入力します。このシェルは、1つのバッチで複数のプロパティを設定する必要がありますが、完全なコマンド構文を入力したくない場合に便利です。

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

ceph-saltのlsコマンドの出力を見るとわかるように、クラスタ構成がツリー構造に整理されます。ceph-saltシェルに含まれる、クラスタの特定のプロパティを設定するには、次の2つのオプションがあります。

ヒント: 設定スニペットの自動補完

ceph-saltシェルの中では自動補完機能を使用できます。これは、通常のLinuxシェル(Bash)の自動補完と同じようなものです。この機能は設定パス、サブコマンド、またはSalt Minion名を補完します。設定パスを自動補完する場合は、次の2つのオプションがあります。

• 現在位置からの相対的なパスをシェルに補完させる場合は、TABキー<Tab>を2回押します。

• シェルに絶対パスを補完させる場合は、/を入力してからTABキー<Tab>を2回押します。

ヒント: 方向キーによる移動

シェルからパスを使用せずにcdceph-saltコマンドを入力すると、ツリー構造のクラスタ構成が出力され、現在パスの行がアクティブになります。上下の方向キーを使用して、それぞれの行に移動できます。Enterを押して確定すると、アクティブ行に設定パスが変更されます。

重要: 表記

ドキュメントの整合性を維持するため、ceph-saltシェルを入力しない単一のコマンド構文を使用しています。たとえば、次のコマンドを使用してクラスタ構成のツリーを一覧にできます。

root@master # ceph-salt config ls

第6章 「Saltの展開」で展開し受諾したSalt Minionの全体またはサブセットをCephクラスタ構成に含めます。Salt Minionはフルネームで指定できます。また、「*」と「?」のグロブ表現を使用することで複数のSalt Minionを同時に含めることもできます。/ceph_cluster/minionsパスでaddサブコマンドを使用します。次のコマンドは受諾済みのSalt Minionをすべて含めます。

root@master # ceph-salt config /ceph_cluster/minions add '*'

指定したSalt Minionが追加されたことを確認します。

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

Cephクラスタに属し、cephadmで管理するノードを指定します。Cephサービスを実行するすべてのノードと、管理ノードを含めます。

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

管理ノードは、ceph.conf設定ファイルとCeph管理キーリングがインストールされるノードです。通常、Ceph関連のコマンドは管理ノードで実行します。

ヒント: 同じノード上のSalt Masterと管理ノード

すべての、または、ほとんどのホストがSUSE Enterprise Storageに所属するような均質な環境では、Salt Masterと同じホストに管理ノードを置くことお勧めします。

あるSaltインフラストラクチャが複数のクラスタのホストとなるような異種環境(たとえば、SUSE Enterprise Storageと共にSUSE Managerを使用するような環境)では、Salt Masterと同じホストに管理ノードを置かないでください。

管理ノードを指定するには、次のコマンドを実行します。

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]

ヒント: ceph.confと管理キーリングを複数のノードにインストールする

展開で必要な場合は、Ceph設定ファイルと管理キーリングを複数のノードにインストールすることもできます。セキュリティ上の理由から、すべてのクラスタのノードにインストールすることは避けてください。

クラスタをブートストラップするSalt Minionをクラスタ内から指定する必要があります。このミニオンはCeph MonitorとCeph Managerサービスを実行する最初のミニオンになります。

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

さらに、public_networkパラメータが正しく設定されていることを確認するために、パブリックネットワーク上のブートストラップMONのIPアドレスを指定する必要があります。たとえば、次のコマンドを実行します。

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

クラスタの中から、アクティブに調整されるプロファイルを保有するミニオンを指定する必要があります。そのためには、次のコマンドを実行して役割を明示的に追加してください。

注記

1つのミニオンにlatencyとthroughputの両方の役割を持たせることはできません。

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

cephadmはSSHプロトコルを使用してクラスタノードと通信します。cephadmという名前のユーザアカウントが自動的に作成され、SSH通信に使用されます。

SSHキーペアの公開鍵と秘密鍵を生成する必要があります。

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

すべてのクラスタノードは信頼できるタイムソースと時刻を同期する必要があります。時刻を同期するには、いくつかのシナリオがあります。

次のコマンドでタイムサーバの設定を確認します。

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

時刻同期設定の詳細については、https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yastを参照してください。

基本的なクラスタが展開されると、Cephダッシュボードが使用可能になります。アクセスするには、有効なユーザ名とパスワードを設定する必要があります。次に例を示します。

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD

ヒント: パスワードの更新を強制する

デフォルトでは、最初のダッシュボードユーザはダッシュボードに最初にログインの際にパスワードの変更を求められます。機能を無効化するには、次のコマンドを実行します。

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

Cephクラスタは、コンテナ化されたCephサービスをダウンロードして展開できるように、コンテナレジストリにアクセスできる必要があります。レジストリにアクセスするには、次の2つの方法があります。

7.2.10.1 ローカルレジストリの作成と設定(オプション) #

 

重要

ローカルレジストリを作成するさまざまな方法があります。このセクションの手順は、セキュアなレジストリと非セキュアなレジストリを作成する例です。コンテナイメージレジストリの実行に関する一般的な情報については、https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installationを参照してください。

ヒント: 配置とポートの使用

クラスタ内のすべてのノードがアクセスできるマシンにレジストリを展開します。管理ノードをお勧めします。デフォルトでは、レジストリはポート5000でリスンします。

レジストリノードで、次のコマンドを使用して、ポートが空いていることを確認します。

ss -tulpn | grep :5000

他のプロセス(iscsi-tcmuなど)がすでにポート5000でリスンしている場合は、レジストリコンテナのポート5000にマップするために使用できる別の空きポートを確認します。

手順 7.1: ローカルレジストリの作成 #

 

1. Containers Module拡張機能が有効になっていることを確認します。

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. 次のパッケージがインストールされていることを確認します: apache2-utils (セキュアなレジストリを有効にしている場合)、cni、cni-plugins、podman、podman-cni-config、およびskopeo。

3. 次の情報を収集します。

   • レジストリホスト(REG_HOST_FQDN)の完全修飾ドメイン名。

   • 5000のレジストリコンテナポート(REG_HOST_PORT)にマップするために使用される使用可能なポート番号。

   • レジストリがセキュアか非セキュアかどうか(insecure=[true|false])。

4. 非セキュアなレジストリ(SSL暗号化なし)を開始するには、次の手順に従います。

   1. 非セキュアなレジストリのceph-saltを設定します。

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. 必要なディレクトリ(たとえば、/var/lib/registry)を作成し、podmanコマンドを使用してレジストリを開始することにより、非セキュアなレジストリを開始します。

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. 再起動後にレジストリを開始するには、レジストリのsystemdユニットファイルを作成して有効にします。

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. セキュアなレジストリを開始するには、次の手順に従います。

   1. 必要なディレクトリを作成します。

      # mkdir -p /var/lib/registry/{auth,certs}

   2. SSL証明書を生成します。

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      注記

      CN=[value]の値をホストの完全修飾ドメイン名([REG_HOST_FQDN])に設定します。

   3. 証明書をすべてのクラスタノードにコピーし、証明書キャッシュを更新します。

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. レジストリへの認証用にユーザ名とパスワードの組み合わせを生成します。

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. セキュアなレジストリを開始します。REGISTRY_STORAGE_DELETE_ENABLED=trueフラグを使用して、後でskopeo deleteコマンドを使用してイメージを削除できるようにします。

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. レジストリへのセキュアなアクセスをテストします。

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. ローカルレジストリが作成されたら、registry.suse.comにある公式のSUSEレジストリからローカルレジストリにコンテナイメージを同期する必要があります。同期するために、skopeoパッケージに含まれているskopeo syncコマンドを使用できます。詳細については、マニュアルページ(man 1 skopeo-sync)を参照してください。次に例を示します。

   例 7.1: マニフェストファイルの表示 #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   例 7.2: ディレクトリに同期 #

    

   すべてのCephイメージを同期します。

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   最新のイメージのみを同期します。

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   例 7.3: Grafanaイメージを同期 #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   最新のGrafanaイメージのみを同期します。

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   例 7.4: 最新のPrometheusイメージを同期 #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

手順 7.2: ローカルレジストリを設定し、資格情報にアクセスする #

 

1. ローカルレジストリのURLを設定します。

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REG_HOST_URL

2. ローカルレジストリにアクセスするためのユーザ名とパスワードを設定します。

   cephuser@adm > ceph-salt config /containers/registry_auth/username set REG_USERNAME

   cephuser@adm > ceph-salt config /containers/registry_auth/password set REG_PASSWORD

ヒント: レジストリキャッシュ

更新されたコンテナが新しく登場した際にローカルレジストリを再同期しないようにするには、「レジストリキャッシュ」を設定できます。

7.2.10.2 コンテナイメージへのパスの設定 #

 

重要

このセクションでは、ブートストラップクラスタのコンテナイメージへのパスを設定する方法を説明します(最初のCeph MonitorとCeph Managerのペアの展開)。パスは、監視スタックなどの追加サービスのコンテナイメージには適用されません。

ヒント: HTTPSプロキシの設定

プロキシを使用してコンテナレジストリサーバと通信する必要がある場合は、すべてのクラスタノードで次の設定手順を実行します。

1. コンテナの設定ファイルをコピーします。

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. 新しくコピーしたファイルを編集し、http_proxy設定を[engine]セクションに追加します。次に例を示します。

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

cephadmは、コンテナイメージへの有効なURIパスを知っている必要があります。次のコマンドを実行して、デフォルト設定を確認します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

代替レジストリまたはローカルレジストリが必要ない場合は、デフォルトのSUSEコンテナレジストリを指定します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7.1/ceph/ceph

ローカルレジストリへのパスなど、展開に特定のパスが必要な場合は、次のように設定します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

MSGR2プロトコルは、Cephの通信プロトコルです。このプロトコルは、ネットワークを通過するすべてのデータを暗号化するセキュリティモードを提供し、認証ペイロードをカプセル化し、新しい認証モード(Kerberosなど)を将来的に統合することを可能にします。

重要

現在のところ、CephFSやRADOS Block Deviceなどの、LinuxカーネルのCephFSクライアントはmsgr2をサポートしていません。

Cephデーモンは複数のポートにバインドできるため、古いCephクライアントとv2対応の新しいクライアントが同じクラスタに接続できます。デフォルトでは、MONはIANAが新しく割り当てた3300番ポート(CE4hまたは0xCE4)と、過去のデフォルトポートである6789番ポートにバインドされます。前者は新しいv2プロトコル用で、後者は旧式のv1プロトコル用です。

v2プロトコル(MSGR2)は2つの接続モードに対応しています。

ほとんどの接続については、オプションで使用するモードを制御できます。

Monitorだけに適用される、同様のオプションセットが存在します。これにより、管理者がMonitorとの通信に異なる要求(通常はより厳しい要求)を設定することができます。

展開中にMSGR2の暗号化モードを有効化するには、ceph-salt設定に設定オプションをいくつか追加してからceph-salt applyを実行します。

secureモードを使用するには、次のコマンドを実行します。

設定ツールのceph_confceph-saltにグローバルセクションを追加します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

次のオプションを設定します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"

注記

crcの前にsecureがついているか確認してください。

secureモードを強制するには、次のコマンドを実行します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure

ヒント: 設定の更新

上記の設定を変更したい場合、Monitor設定の保存先に変更内容を設定します。その手段として、ceph config setコマンドを使用します。

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

例:

root@master # ceph config set global ms_cluster_mode "secure crc"

現在値やデフォルト値を確認したい場合は、次のコマンドを実行します。

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

たとえば、OSDのms_cluster_modeを取得するには、次のコマンドを実行します。

root@master # ceph config get osd ms_cluster_mode

必要に応じて分離されたクラスタネットワークを実行する場合は、クラスタのネットワークIPアドレスの末尾にスラッシュ記号で区切ったサブネットマスクを付加したアドレスを設定する必要がある場合があります。たとえば、192.168.10.22/24のようなアドレスです。

cluster_networkを有効化するには、次のコマンドを実行します。

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

最低限のクラスタ設定が完了しました。明らかな誤りがないか、確認してください。

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .............. [registry.suse.com/ses/7.1/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]

ヒント: クラスタ設定のステータス

次のコマンドを実行することで、クラスタ設定が有効かどうかを確認できます。

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

基本的なクラスタの設定が完了し、設定が有効であること確認したら、クラスタ設定をファイルにエクスポートするとよいでしょう。

root@master # ceph-salt export > cluster.json

警告

ceph-salt exportの出力にはSSHの秘密鍵が含まれます。セキュリティ上の不安がある場合は、適切な予防策を講じるまではコマンドを実行しないでください。

クラスタ設定を破棄してバックアップの状態に戻す場合は、次のコマンドを実行します。

root@master # ceph-salt import cluster.json

次のコマンドは、Cephオーケストレータの現在モードとステータスを表示します。

cephuser@adm > ceph orch status

すべてのディスクデバイスを一覧にするには、次のコマンドを実行します。

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]

ヒント: サービスとデーモン

「サービス」とは、特定のタイプのCephサービスを指す総称です。たとえば、Ceph Managerなどです。

「デーモン」とは、サービスの特定のインスタンスを指します。たとえば、ses-min1という名前のノードで実行されるmgr.ses-min1.gdlcikプロセスなどです。

cephadmが認識しているすべてのサービスを一覧にするには、次のコマンドを実行します。

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd

ヒント

リストに特定のノードのサービスだけを表示するには、オプションの-–hostパラメータを使用します。特定のタイプのサービスだけを表示するには、オプションの--service-typeパラメータを使用します。指定できるタイプは、mon、osd、mgr、mds、およびrgwです。

cephadmが展開した実行中のすべてのデーモンを一覧にするには、次のコマンドを実行します。

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369

ヒント

特定のデーモンのステータスを照会するには、--daemon_typeと--daemon_idを使用します。OSDの場合、IDは数字のOSD IDです。MDSの場合、IDはファイルシステム名です。

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

サービスタイプごとに個別の仕様ファイルを作成できます。以下に例を示します。

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

もしくは、各サービスを実行するノードを記載した単一のファイル(cluster.ymlなど)により、複数の(または、すべての)サービスタイプを指定することもできます。それぞれのサービスタイプを3つのダッシュ記号(---)で区切ることを忘れないでください。

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

各プロパティが意味するものは、以下の通りです。

ヒント: 特定のサービスを適用する

通常、Cephクラスタのサービスには、いくつかの固有のプロパティがあります。個別のサービス仕様の例と詳細については、8.3項 「Cephサービスの展開」を参照してください。

Cephサービスを展開するには、サービスの展開先ノードをcephadmが認識する必要があります。placementプロパティを使用して、サービスを適用するノードのホスト名の略称を列挙してください。

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

すべてのサービス仕様とサービスの配置仕様を記載した完全なcluster.ymlファイルの作成が完了したら、次のコマンドを実行して、クラスタに仕様を適用してください。

cephuser@adm > ceph orch apply -i cluster.yml

クラスタのステータスを確認するには、ceph orch statusコマンドを実行します。詳細については、「8.1.1項 「オーケストレータステータスの表示」」を参照してください。

8.2項 「サービス仕様と配置仕様」で説明した仕様ファイルを用いてCephクラスタにサービスを展開したにもかかわらず、運用中にクラスタの設定が元の仕様から変わる場合もあります。また、誤って仕様ファイルを削除してしまうことも考えられます。

実行中のクラスタからすべての仕様を取得するには、次のコマンドを実行してください。

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]

ヒント

--formatオプションを付加することで、デフォルトのyaml出力フォーマットを変更できます。選択できるフォーマットは、json、json-pretty、yamlです。以下に例を示します。

ceph orch ls --export --format json

Cephクラスタでは、3個または5個のMONを異なるノードに展開します。クラスタに5個以上のノードが含まれる場合、5個のMONを展開することをお勧めします。MONと同じノードにMGRを展開すると良いでしょう。

重要: ブートストラップMONを含める

MONとMGRを展開する際は、7.2.5項 「最初のMON/MGRノードの指定」で基本的なクラスタを構成した際に追加した、最初のMONを忘れずに含めてください。

MONを展開するには、次の仕様を適用してください。

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

注記

別のノードを追加する必要がある場合は、同じYAMLリストにホスト名を付加してください。以下に例を示します。

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

同様に、MGRを展開するには次の仕様を適用してください。

重要

展開ごとに、少なくとも3個のCeph Managerが展開されているかを確認してください。

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

ヒント

MONまたはMGRが同じサブネット上に存在しない場合、サブネットアドレスを付加する必要があります。以下に例を示します。

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

重要: ストレージデバイスが使用可能となる条件

以下の条件をすべて満たす場合、ストレージデバイスは「使用可能」とみなされます。

• デバイスにパーティションが作成されていない。

• デバイスがLVM状態ではない。

• デバイスがマウント先になっていない。

• デバイスにファイルシステムが含まれない。

• デバイスにBlueStore OSDが含まれない。

• デバイスのサイズが5GBを超えている。

これらの条件が満たされない場合、CephはそのOSDのプロビジョニングを拒否します。

OSDを展開する方法は2つあります。

CephFSは1つ以上のMDS(メタデータサーバ)サービスを必要とします。CephFSを作成するには、まず以下の仕様を適用して、MDSサーバを作成する必要があります。

注記

最低でも2つのプールを作成してから以下の仕様を適用してください。1つはCephFSのデータ用、もう1つはCephFSのメタデータ用のプールです。

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

MDSが機能したら、CephFSを作成します。

ceph fs new CEPHFS_NAME metadata_pool data_pool

cephadmはObject Gatewayを、特定の「レルム」と「ゾーン」を管理するデーモンのコレクションとして展開します。

Object Gatewayサービスを既存のレルムとゾーンに関連付けることも(詳細については、Book “運用と管理ガイド”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “マルチサイトObject Gateway”を参照してください)、存在しないREALM_NAMEとZONE_NAMEを指定することもできます。後者の場合、次の設定を適用すると自動的にゾーンとレルムが作成されます。

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

8.3.4.1 セキュアなSSLアクセスの使用 #

 

Object Gatewayへの接続にセキュアなSSL接続を使用するには、有効なSSL証明書とキーファイルのペアが必要です(詳細については、Book “運用と管理ガイド”, Chapter 21 “Ceph Object Gateway”, Section 21.7 “Object GatewayでのHTTPS/SSLの有効化”を参照してください)。必要な作業は、SSLの有効化、SSL接続のポート番号の指定、SSL証明書とキーファイルの指定です。

SSLを有効化し、ポート番号を指定するには、仕様に次の内容を記載します。

spec:
  ssl: true
  rgw_frontend_port: 443

SSL証明書とキーを指定するには、YAML仕様ファイルに内容を直接ペーストすることができます。行末のパイプ記号(|)は、構文解析の際に複数行にまたがる文字列を1つの値として認識させるためのものです。以下に例を示します。

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----

ヒント

SSL証明書とキーファイルの内容をペーストする代わりに、rgw_frontend_ssl_certificate:キーワードとrgw_frontend_ssl_key:キーワードを削除して、設定データベースにSSL証明書とキーファイルをアップロードすることもできます。

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE

8.3.4.1.1 ポート443と80の両方でリスンするようにObject Gatewayを設定する #

 

ポート443 (HTTPS)とポート80 (HTTP)の両方でリスンするようにObject Gatewayを設定するには、次の手順に従います。

注記

この手順のコマンドは、レルムとゾーンのdefaultを使用します。

1. 仕様ファイルを提供して、Object Gatewayを展開します。Object Gateway仕様の詳細については、8.3.4項 「Object Gatewayの展開」を参照してください。次のコマンドを実行します。

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. SSL証明書が仕様ファイルで提供されていない場合は、次のコマンドを使用してSSL証明書を追加します。

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. rgw_frontendsオプションのデフォルト値を変更します。

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. cephadmによって作成された特定の設定を削除します。次のコマンドを実行して、rgw_frontendsオプションが設定されているターゲットを特定します。

   cephuser@adm > ceph config dump | grep rgw

   たとえば、ターゲットはclient.rgw.default.default.node4.yiewduです。現在の特定のrgw_frontends値を削除します。

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   ヒント

   rgw_frontendsの値を削除する代わりに指定できます。例:

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Object Gatewayを再起動します。

   cephuser@adm > ceph orch restart rgw.default.default

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

cephadmが展開するiSCSI Gatewayは、クライアント(「イニシエータ」)から、リモートサーバ上のSCSIストレージデバイス(「ターゲット」)にSCSIコマンドを送信できるようにする、SAN(ストレージエリアネットワーク)プロトコルです。

展開するには以下の設定を適用します。trusted_ip_listにすべてのiSCSI GatewayノードとCeph ManagerノードのIPアドレスが含まれているか確認してください(以下の出力例を参照してください)。

注記

以下の仕様を適用する前に、プールが作成されているか確認してください。

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"

注記

trusted_ip_listに列挙されたIPについて、カンマ区切りの後にスペースが入っていないことを確認してください。

spec:
  api_secure: true

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

重要

NFS Ganeshaは、NFSバージョン4.1以降をサポートしています。NFSバージョン3はサポートしていません。

cephadmはNFS Ganeshaの展開に、事前定義されたRADOSプールとオプションのネームスペースを使用します。NFS Ganeshaを展開するには、次の仕様を適用してください。

注記

事前定義されたRADOSプールが必要です。これが存在しない場合は、ceph orch apply処理に失敗します。プールの作成の詳細については、Book “運用と管理ガイド”, Chapter 18 “ストレージプールの管理”, Section 18.1 “プールの作成”を参照してください。

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

rbd-mirrorサービスは2つのCephクラスタ間でRADOS Block Deviceイメージの同期を行います(詳細についてはBook “運用と管理ガイド”, Chapter 20 “RADOS Block Device”, Section 20.4 “RBDイメージのミラーリング”を参照してください)。rbd-mirrorを展開するには、次の仕様を使用してください。

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

監視スタックは、Prometheus、Prometheusエクスポータ、Prometheus Alertmanager、Grafanaから構成されます。Cephダッシュボードはこうしたコンポーネントを利用して、クラスタの使用量やパフォーマンスの詳細なメトリクスの保存と視覚化を行います。

ヒント

展開に監視スタックサービスのカスタムコンテナイメージやローカルコンテナイメージを必要とする場合は、Book “運用と管理ガイド”, Chapter 16 “監視とアラート”, Section 16.1 “カスタムイメージまたはローカルイメージの設定”を参照してください。

監視スタックを展開するには、以下の手順に従ってください。

重要

Prometheus、Grafana、Cephダッシュボードは、お互いに通信できるようにすべて自動的に設定されます。そのため、この手順で展開されたとき、Cephダッシュボードには完全に機能するGrafanaが統合されています。

このルールの例外は、RBDイメージの監視だけです。詳細については、Book “運用と管理ガイド”, Chapter 16 “監視とアラート”, Section 16.5.4 “RBDイメージ監視の有効化”を参照してください。

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を強くお勧めします。

ceph-iscsiは、RADOS Block Deviceの利点とiSCSIのユビキタスな汎用性を組み合わせたものです。iSCSIターゲットホスト(iSCSI Gatewayとして知られている)上でceph-iscsiを使用することで、Cephクライアントプロトコルに対応していなくても、ブロックストレージを利用する必要があるすべてのアプリケーションがCephの利点を享受できます。代わりに、ユーザはiSCSIまたは他のターゲットフロントエンドプロトコルを使用してLIOターゲットに接続できます。これにより、そのターゲットがすべてのI/OをRBDストレージ操作に変換します。

図 9.1: 1つのiSCSI Gatewayで構成されるCephクラスタ #

 

ceph-iscsiは本質的に高可用性であり、マルチパス操作をサポートしています。したがって、ダウンストリームのイニシエータホストは、複数のiSCSI Gatewayを使用して高可用性とスケーラビリティの両方を実現できます。複数のゲートウェイで構成されるiSCSI設定で通信する場合、イニシエータはiSCSI要求を複数のゲートウェイに負荷分散できます。ゲートウェイに障害が発生したり、一時的にアクセス不可能であったり、保守のために無効になっていたりする場合、I/Oは別のゲートウェイ経由で透過的に継続されます。

図 9.2: 複数のiSCSI Gatewayで構成されるCephクラスタ #

 

SUSE Enterprise Storage 7.1とceph-iscsiの最小設定は以下のコンポーネントで構成されます。

SUSE Enterprise Storage 7.1とceph-iscsiの推奨運用設定は以下で構成されます。

このセクションでは、SUSE Enterprise StorageにiSCSI Gatewayをインストールして設定する手順について説明します。

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

9.1.4.3 iSCSIを経由したRBDイメージのエクスポート #

 

iSCSI経由でRBDイメージをエクスポートするには、CephダッシュボードWebインタフェースか、ceph-iscsi gwcliユーティリティのいずれかを使用できます。このセクションでは、gwcliにのみ焦点を当て、コマンドラインを使用してRBDイメージをエクスポートするiSCSIターゲットを作成する方法を示します。

注記

次のプロパティを持つRBDイメージは、iSCSI経由ではエクスポートできません。

• journaling機能が有効化されたイメージ

• stripe unitが4096バイト未満のイメージ

rootととして、iSCSI Gatewayのコンテナを入力します。

# cephadm enter --name CONTAINER_NAME

rootとして、iSCSI Gatewayのコマンドラインインタフェースを起動します。

# gwcli

iscsi-targetsに移動して、次の名前のターゲットを作成します。iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

iSCSI Gatewayのnameとipアドレスを指定して、ゲートウェイを作成します。

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

ヒント

現在の設定ノードで使用可能なコマンドのリストを表示するには、helpコマンドを使用します。

testvolという名前のRBDイメージをプールiscsi-imagesに追加します。

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

RBDイメージをターゲットにマップします。

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol

注記

targetcliなどの下位レベルのツールを使用してローカル設定を照会することができますが、設定を変更しないでください。

ヒント

lsコマンドを使用して、設定を確認できます。一部の設定ノードは、infoコマンドもサポートしています。このコマンドを使用すると、詳細情報を表示できます。

デフォルトではACL認証が有効になっているため、このターゲットにはまだアクセスできません。認証とアクセス制御の詳細については、9.1.4.4項 「認証とアクセス制御」を確認してください。

9.1.4.4 認証とアクセス制御 #

 

iSCSI認証は柔軟性があり、多数の認証方法に対応しています。

9.1.4.4.1 ACL認証の無効化 #

 

「認証なし」とは、イニシエータが、対応するターゲット上のすべてのLUNにアクセスできることを意味します。「認証なし」を有効にするには、ACL認証を無効にします。

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

9.1.4.4.2 ACL認証の使用 #

 

イニシエータ名ベースのACL認証の使用時には、定義されたイニシエータのみが接続を許可されます。以下を実行して、イニシエータを定義できます。

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

定義されているイニシエータは接続できますが、イニシエータに明示的に追加されたRBDイメージにのみアクセスできます。

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

9.1.4.4.3 CHAP認証の有効化 #

 

ACLに加えて、各イニシエータのユーザ名とパスワードを指定して、CHAP認証を有効にできます。

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

注記

ユーザ名は8～64文字の長さが必要で、英数字と記号「.」、「@」、「-」、「_」、「:」を使用できます。

パスワードは12～16文字の長さが必要で、英数字と記号「@」、「-」、「_」、「/」を使用できます。

必要に応じて、authコマンドでmutual_usernameパラメータとmutual_passwordパラメータを指定して、CHAP相互認証を有効にすることもできます。

9.1.4.4.4 検出認証と相互認証の設定 #

 

「検出認証」は、前の認証方法とは異なります。参照用の資格情報が必要です。これはオプションで、次のコマンドによって設定できます。

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

注記

ユーザ名は8～64文字の長さが必要で、英数字と記号「.」、「@」、「-」、「_」、「:」のみ使用できます。

パスワードは12～16文字の長さが必要で、英数字と記号「@」、「-」、「_」、「/」を使用できます。

オプションで、discovery_authコマンドでmutual_usernameパラメータとmutual_passwordパラメータを指定することもできます。

検出認証は、次のコマンドを使用して無効にすることができます。

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 高度な設定 #

 

高度なパラメータを使用してceph-iscsiを設定し、設定したパラメータをその後LIO I/Oターゲットに渡すことができます。パラメータは、ターゲットのパラメータとディスクのパラメータに分かれています。

警告

特に明記されていない限り、これらのパラメータをデフォルト設定から変更することは推奨しません。

9.1.4.5.1 ターゲット設定の表示 #

 

infoコマンドを使用して、これらの設定の値を表示できます。

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

また、reconfigureコマンドを使用して、設定を変更します。

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

使用可能なターゲット設定は、次のとおりです。

default_cmdsn_depth

CmdSN (コマンドシーケンス番号)のデフォルトの深さ。特定の時点でiSCSIイニシエータが未処理の状態にしておくことができる要求の量を制限します。

default_erl

デフォルトのエラー回復レベル。

login_timeout

ログインタイムアウトの値(秒)。

netif_timeout

NICの障害タイムアウト(秒)。

prod_mode_write_protect

1に設定すると、LUNへの書き込みを防止します。

9.1.4.5.2 ディスク設定の表示 #

 

infoコマンドを使用して、これらの設定の値を表示できます。

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /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」に設定し、誰かが設定で無効にしようとした場合はエラーをスローするのが理想的です。

unmap_zeroes_data

LIOがLBPRZをSCSIイニシエータにアドバタイズするかどうかに影響します。これは、マップ解除ビットを使用したUNMAPまたはWRITE SAMEの後に、領域から0が読み込まれることを示します。

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機能が有効になっている必要があります。

アップグレードの前に以下のセクションを熟読して、実行する必要があるすべてのタスクを十分に理解してください。

SUSE Enterprise Storage 7.1へのアップグレードを開始する前に、すべてのクラスタ設定とデータをバックアップすることを強くお勧めします。すべてのデータをバックアップする方法については、https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backupを参照してください。

以前にバージョン5からアップグレードした場合は、バージョン6へのアップグレードが正常に完了していることを確認します。

/srv/salt/ceph/configuration/files/ceph.conf.importというファイルが存在することを確認します。

このファイルはSUSE Enterprise Storage 5から6へのアップグレード中に、engulfプロセスにより作成されます。configuration_init: default-importオプションは/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.ymlに設定されます。

configuration_initがまだdefault-importに設定されている場合、クラスタはその設定ファイルとしてceph.conf.importを使用しています。これは、/srv/salt/ceph/configuration/files/ceph.conf.d/にあるファイルからコンパイルされるDeepSeaのデフォルトのceph.confではありません。

したがって、ceph.conf.importでカスタム設定を調べ、可能であれば、/srv/salt/ceph/configuration/files/ceph.conf.d/にあるファイルのいずれかに設定を移動する必要があります。

その後、/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.ymlからconfiguration_init: default-import行を削除してください。

SUSE Linux Enterprise Server 15 SP1とSUSE Enterprise Storage 6のすべての最新のアップデートがすべてのクラスタノードに適用されていることを確認してください。

# zypper refresh && zypper patch

ヒント

クラスタノードの更新の詳細については、https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updatesを参照してください。

更新が適用されたら、Salt Masterを再起動し、新しいSaltモジュールを同期して、クラスタヘルスを確認します。

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

各クラスタノードがSUSE Linux Enterprise Server 15 SP3とSUSE Enterprise Storage 7.1のソフトウェアリポジトリとコンテナイメージのリポジトリにアクセスできることを確認してください。

SUSE Enterprise Storage 7.1においてObject Gatewayは常にレルムに設定されます。これにより、将来的なマルチサイトが可能になります(詳細についてはBook “運用と管理ガイド”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “マルチサイトObject Gateway”を参照してください)。SUSE Enterprise Storage 6でシングルサイトのObject Gateway設定を使用している場合は、以下の手順に従ってレルムを追加してください。マルチサイト機能を使う予定がない場合は、レルム、ゾーングループ、ゾーンの名前にdefaultを使用してもかまいません。

Object Gatewayサービスをコンテナ化するには、8.3.4項 「Object Gatewayの展開」に記載されている仕様ファイルを作成し、適用します。

cephuser@adm > ceph orch apply -i RGW.yml

重要

NFS Ganeshaは、NFSバージョン4.1以降をサポートしています。NFSバージョン3はサポートしていません。

Ceph Nautilusを実行する既存のNFS Ganeshaサービスから、Ceph Octopusを実行するNFS Ganeshaコンテナにマイグレートする方法を次で説明します。

警告

以下の情報は、コアとなるCephサービスのアップグレードに成功していることを前提としたものです。

NFS Ganeshaはデーモンごとの追加設定を保存し、RADOSプールに設定をエクスポートします。設定済みのRADOSプールは、ganesha.confファイルのRADOS_URLSブロックのwatch_url行で確認できます。デフォルトでは、このプールはganesha_configと名付けられます。

マイグレーションを試みる前に、RADOSプールにあるエクスポートおよびデーモン設定オブジェクトのコピーを作成することを強くお勧めします。設定されたRADOSプールを見つけるには、次のコマンドを実行します。

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

RADOSプールの内容を一覧にするには、次のコマンドを実行します。

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

RADOSオブジェクトをコピーするには、次のコマンドを実行します。

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

ノードごとに既存のNFS Ganeshaサービスを停止して、cephadmが管理するコンテナに置き換える必要があります。

既存のエクスポートは次の2つの方法でマイグレートできます。

サービスのマイグレートに成功すると、NautilusベースのNFS Ganeshaサービスを削除できるようになります。

MON、MGR、OSDとは異なり、メタデータサーバをインプレース導入することはできません。その代わり、Cephオーケストレータを使用して、コンテナ内に再展開する必要があります。

iSCSI Gatewayをアップグレードするには、Cephオーケストレータを使用してコンテナ内に再展開する必要があります。複数のiSCSI Gatewayを使用している場合はサービスのダウンタイムを短縮するために、iSCSI Gatewayを1つずつ再展開する必要があります。

アップグレードの前に以下のセクションを熟読して、実行する必要があるすべてのタスクを十分に理解してください。

アップグレードを開始する前に、すべてのクラスタ設定とデータをバックアップすることを強くお勧めします。すべてのデータをバックアップする方法については、Book “運用と管理ガイド”, Chapter 15 “バックアップおよび復元”を参照してください。

各クラスタノードがSUSE Linux Enterprise Server 15 SP3とSUSE Enterprise Storage 7.1のソフトウェアリポジトリとコンテナイメージのリポジトリにアクセスできることを確認してください。