CEPH RBDおよびGFS2に基づく共有ストレージの作成

クラスタシステムのほとんどのソフトウェアには、クラスタ内のすべてのノードから利用可能なファイルシステムが必要です。 このファイルシステムは、ソフトウェア、データの保存、いくつかのクラスターサブシステムの操作の整理などに使用されます。 このようなFSのパフォーマンス要件は、タスクによって大きく異なる場合がありますが、それが高いほど、クラスターはより安定しており、普遍的であると考えられます。 マスターノード上のNFSサーバーは、このようなFSの最小バージョンです。 大規模なクラスターの場合、NFSはLustreFSの展開によって補完されます。LustreFSは、ファイルストレージおよび複数のメタ情報サーバーとして複数のサーバーを使用する、高性能で特殊な分散ファイルシステムです。 ただし、この構成には多数のプロパティがあり、クライアントが独立した仮想化クラスターを使用する場合、この構成での作業が非常に難しくなります。 HPC HUB vSCは、よく知られているCEPHソリューションとGFS2ファイルシステムを使用して、共有FSを作成します。





OpenStackに基づくHPC HUBプロジェクトの作業の一環として、それぞれが小さな仮想HPCクラスターである仮想マシンのいくつかのグループ用にフォールトトレラントで高性能な共有ストレージを作成するタスクが発生しました。 このような各クラスターは個々のクライアントに発行され、クライアントは内部から完全に制御します。 したがって、物理コンピューター上で組み立てられた「通常の」分散システムのフレームワーク内で問題を解決することはできません。 イーサネットクラスタネットワークは、L2レベルで互いに分離されており、クライアントデータとネットワークトラフィックを互いに保護します。 さらに、古典的な共有システムのフレームワーク内の各仮想マシンにデータを配置することはできません。各マシンの能力が十分ではなく、特にペイパーの使用を考慮して、「データ輸血」に費やすことなく、計算が完了した直後に貴重なプロセッサーリソースを解放したいためです-使用。 幸いなことに、すべてがそれほど悪いわけではありません。 共有ストレージはHPCの計算に使用されることになっているという事実に照らして、いくつかの負荷を想定できます。

• 操作は大きなブロックで実行されます。
• 書き込み操作は頻繁に行われませんが、かなりの時間間隔で散在します。
• 書き込み操作はすべてのノードからほぼ同時にすぐに開始できますが、この場合でも、できるだけ早く記録を終了して、ノードがカウントを続けるようにする必要があります。

データが計算され、同時に保存されるノードを持つピアツーピアシステムは、原則としてHPCパラダイムに反します。 2つの非同期アクティビティがノードに表示されます。他のノードからのデータをカウントおよび記録します。 最初はそれを放棄せざるを得ませんでした。 2レベルのシステムを構築することが決定されました。 このようなストレージにはいくつかのアプローチがあります。

1. OpenStackネットワーク仮想化によるパフォーマンスの低下を回避するために、特別に編成されたネットワークデバイスを介して仮想ノードにマウントされた分散ファイルシステム。
   
   
2. 物理ノードにマウントされた分散ファイルシステムと、仮想ファイルシステムを介したゲストシステムからのアクセス。
   
   
3. ゲストブロックデバイスの上の仮想クラスター内の古典的な分散ファイルシステム。
   
   
4. 各仮想ノードに共通の分散ブロックデバイスと、この共有デバイス上で実行される仮想クラスター内の事前構成済みファイルシステム。
   
   

これらのアプローチの長所と短所を分析してみましょう。



オプション1）では、従来の分散ファイルシステム（またはサブツリー）がゲストOSにマウントされます。 この場合、ファイルシステムサーバーは各システムから、および相互に表示されます。 これは、L2レベルによるネットワークの分離に違反し、異なるユーザーが保存されたデータを使用して互いのトラフィックを見る可能性があります。 さらに、CEPHの場合、カーネルでは直接ではなく、FUSE（ユーザー空間のファイルシステム）を介してファイルシステムのマウントモードで協調クォータのみが可能です（つまり、ユーザーは許可されたディスクスペースを他のユーザーの費用で再利用できます）。 カーネルに直接マウントされた場合、クォータはまったくサポートされません。



オプション2）-ホストにマウントされた分散ファイルシステムの上にある仮想ファイルシステム（QEMUのvirtio-9p）-動作するには、特権を下げることなくスーパーユーザーの代わりにQEMUを実行する必要があります。これにより、システムの全体的なセキュリティが低下するか、ゲストIDを保存する特定のACLが構成されますユーザーおよびゲストのアクセス権。



オプション3）では、物理サーバーにディスクスペースがない場合、一部の分散ストレージのリモートブロックデバイスのみを使用できます。 このオプションは、いくつかの理由で実用的ではありません。

• データにアクセスするには、ネットワーク帯域幅の2倍が必要です。 データは、最初に分散ストレージから特定の仮想ホストに転送されてから、最終消費者にのみ送信されます。
  
  
  
  
• 原則として、このようなシステムはすべてデータの冗長性をサポートしますが、これは受け入れられません。 たとえば、CEPHのデフォルト設定では、使用可能なストレージ容量はすでに使用可能なディスク容量の4倍に削減されています。 分散FSをサポートするすべてのネットワーク負荷も、仮想ネットワーク空間内にあります。 そして、最も難しいのは、後者のオプションでは実際にストレージ仮想マシンに物理ノードを割り当てる必要があるため、全体的な効率が大幅に低下することです。

オプション4）では、CEPHに基づいた分散ブロックデバイスと、そのようなデバイスで動作するクラスター内の何らかのファイルシステムを試すことにしました。 実際、ゲストはもちろん、デバイスをブロックCEPHデバイスとしてではなく、通常の仮想VirtIO SCSIまたはオプションでVirtIOブロックとして認識します。 VirtIO SCSIを選択したのは非常に簡単な理由です-unmapコマンドのSCSIサポートにより、よく知られているSATA TRIMコマンドに類似しており、ファイルが削除されるとゲストシステムによって送信され、仮想ストレージのスペースを解放します。



ゲスト用のファイルシステムの選択も簡単です。 次の2つのオプションのみがあります。

• OCFS2
• Gfs2。

主流のLinuxではサポートされていない異国情緒は、商用運用には使用されませんでした。 CentOS 7がベースシステムとして採用されたため、OCFS2も表示されなくなります。 コアの骨の折れる再構築はありませんでした。 さらに、GFS2は、マウントされた状態のファイルシステムのサイズ変更をサポートします。これは、この場合に役立つ可能性があります。

共有ストレージ構成

CEPHのインストールは、ドキュメントdocs.ceph.com/docs/master/startで完全に説明されており、特別な問題は発生していません。 現在、システムはデータの冗長コピーを1つ使用し、許可なしで動作します。 CEPHネットワークは、クライアントネットワークから分離されています。 ブロックデバイスを作成しても問題は発生しませんでした。 すべてが標準です。

GFS2の構成

残念ながら、GFS2では、セットアップに当初の予想よりもかなり長い時間がかかりました。 ネット上には説明的な説明はほとんどなく、混乱を招きます。 一般的な考え方は次のとおりです。 カーネル内の共有ファイルシステムの動作は、いくつかのデーモンによって制御されます。デーモンを正しく構成するには、簡単な努力や知識が必要です。



最初に知っておくべき最も重要なことは、Ubuntuでこのファイルシステムを上げることに成功しない可能性が高いことです。 または、Ubuntuの下でRedHatの外部で十分に活用されていない多くのパッケージを再構築し、APIレベルの非自明な競合を解決する必要があります。



RedHatのようなシステムでは、シーケンスは多かれ少なかれ理解されています。 以下は、CentOS 7ゲストシステム用のコマンドです。



まず、SELinuxを無効にします。 GFS2はそれで動作しません。 これはメーカーからの公式情報です。

vi /etc/sysconfig/selinux #  ,     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本的なソフトウェアを配置します。

 yum -y install ntp epel-release vim openssh-server net-tools
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要なサービスをオン/オフにします。

 chkconfig ntpd on chkconfig firewalld off
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

システムが機能するためにはNTPが必要であり、ブロックデバイス領域のすべての分散ブロッキングはそれに関連付けられています。 システムは外界から隔離されたクラスター用に構成されているため、ファイアウォールをオフにします。 次に、必要なソフトウェアバインディングを各クラスターノードに配置します。

 yum -y install gfs2-utils lvm2-cluster pcs fence-agents-all chkconfig pcsd on #  PaceMaker -  RedHat  lvmconf --enable-cluster #    GFS2    echo <PASSWORD> | passwd --stdin hacluster #    .   :) reboot #   SELinux    LVM
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザー「hacluster」を作成する必要はないことに注意してください。パッケージをインストールするときに、ユーザー「hacluster」は自動的に作成されます。 将来的には、クラスターマシン間の相互認証ネットワークを作成するために彼のパスワードが必要になります。



これで、これまでに行われていなかった分散リポジトリを作成できるようになりました。 これは、CEPHノード、つまり、この例では物理ノードで実行されます。

 rbd create my-storage-name --image-format 2 --size 6291456 #   ! sudo rbd map rbd/my-storage-name sudo mkfs.gfs2 -p lock_dlm -t gfs2:fs -j17 /dev/rbd0 sudo rbd unmap /dev/rbd0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルシステムをフォーマットするとき、クラスター名が示されます-この場合は「gfs2」、このクラスター内のファイルシステムの名前は「fs」、ログの数は「-j17」です。ディスクスペースを割り当てるためのクラスターとロックプロトコル（この場合、「lock_dlm」は分散ロックです）。 パーティションをマウントするときに、クラスターとファイルシステムの名前を指定する必要があります。 クラスター内の分離されたネットワークでは、異なるクラスターに同じ名前を使用できます。 これは問題ではありません。



これで、ゲストOSでマウントを構成するだけになりました。 構成は、クラスターマシンの1つから1回実行されます。

 pcs cluster destroy --all #   ,    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

相互認証ネットワークの作成：

 pcs cluster auth master n01 n02 n03 n04 -u hacluster -p 1q2w3e4r --force
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、masterとn01..n04は、共有パーティションが利用できる仮想ホストです。



デフォルトのクラスターを作成します。 クラスタ名は、前の手順でファイルシステムを作成するときに使用したものと一致する必要があることに注意してください。

 pcs cluster setup --name gfs2 master n01 n02 n03 n04 pcs cluster start --all #     pcs cluster enable --all #      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスデーモンの実行-clvmdおよびdlm：

 pcs property set no-quorum-policy=ignore pcs stonith create local_stonith fence_kdump pcmk_monitor_action="metadata" pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s \ on-fail=fence clone interleave=true ordered=true pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s \ on-fail=fence clone interleave=true ordered=true pcs constraint order start dlm-clone then clvmd-clone pcs constraint colocation add clvmd-clone with dlm-clone
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GFS2パーティションを/ shared、共有ブロックデバイスにマウントする-sdb：

 pcs resource create clusterfs Filesystem device="/dev/sdb" \ directory="/shared" fstype="gfs2" "options=noatime,nodiratime" op \ monitor interval=10s on-fail=fence clone interleave=true pcs constraint order start clvmd-clone then clusterfs-clone pcs constraint colocation add clusterfs-clone with clvmd-clone
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この瞬間から、次のコマンドを使用して、サービスを1つずつ上げるシステム全体の開始を楽しむことができます。

 pcs status resources
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最終的に、すべてが適切に機能した場合、各ノードで/共有ファイルシステムが使用可能になることがわかります。

性能試験

テストでは、ddを介して各ノードからデータを順番に読み書きする簡単なスクリプトを使用しました。次に例を示します。

 dd if=/shared/file of=/dev/null bs=32M iflag=direct dd if=/root/file of=/shared/file bs=32M oflag=direct
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブロックサイズは大きく設定され、読み取りは「直接」モードで行われ、ディスクキャッシュの操作速度ではなく、ファイルシステム自体をテストします。 結果は次のとおりです。









図1 異なるサイズの仮想クラスターのすべてのノードからの同時読み取り。 単一ノードのパフォーマンス。









図2。 異なるサイズの仮想クラスターのすべてのノードからの同時読み取り。 累積パフォーマンス。









図3 異なるサイズの仮想クラスターのすべてのノードからの同時記録。 単一ノードのパフォーマンス。









図4 異なるサイズの仮想クラスターのすべてのノードからの同時記録。 トータルパフォーマンス

結論

どのような結論を出すことができますか：

• 読み取りは実質的にネットワーク帯域幅（〜9 Gbps、Infiniband、IPoIB）に依存し、仮想クラスター内のノード数の増加に応じて適切にスケーリングされます。
  
  
  
  
• 録音は実用的な上限に基づいており、スケーリングされません。 しかし、これまでの仮定を考慮すると、これは私たちに適しています。 このような天井の存在を引き起こしたメカニズムは、私たちにはまだ明らかではありません。

落とし穴

落とし穴には、少なくともクラスターを使用するすべての仮想マシンの最後を正しく停止する必要があります。 そうしないと、ファイルシステムが回復を必要とする状態になる可能性があります。 深刻な問題は、他との同期を失ったpcsクラスターからノードを切断するためのフェンシングの正しい構成です。 しかし、それについては次の記事で詳しく説明します。



この資料は、Andrei Nikolaev、Denis Lunev、Anna Subbotinaによって作成されました。