CNDT2020シリーズ：サイボウズのSREが語る分散ストレージの配置問題を解決するTopoLVMとは

ゼットラボ株式会社の坂下氏によるKubernetesのストレージ技術に関連して、Kubernetesのストレージ配置問題に関するセッションを紹介する。これはKubernetesのストレージとしてRookとCephを使った分散ストレージの配置問題を解説するもので、プレゼンテーションを行ったのはサイボウズのインフラストラクチャーエンジニア、森本健司氏だ。森本氏はサイボウズのインフラストラクチャーを8年間担当しているというベテランで、セッションの内容も実際に運用を行っているエンジニアとしての知見に満ちたものとなった。

サイボウズの森本氏が語るKubernetesのストレージ配置問題

内容はLVM（Logical Volume Manager）を使用してKubernetesのストレージを最適配置する際の問題点と解決策を解説するもので、Kubernetesの他にRook、Cephを活用した事例にサイボウズが開発したオープンソースソフトウェア、TopoLVMを利用している。

サイボウズが開発したTopoLVMを使った事例

TopoLVMはサイボウズの以下のブログに詳細な紹介がされているので参考にされたい。

参考：Kubernetesでローカルストレージを有効活用しよう

TopoLVMは、CSIプラグインとしてKubernetesからストレージへアクセスするために開発されたソフトウェアだ。LVMという名称が示すように複数のサーバーに存在するSSDやHDDを論理的なボリュームとして定義し、それをPodのスケジューラーに対して提供することでダイナミックにストレージをPodにアサインできるようになる。ちなみにTopologyはKubernetes 1.17でGAとなった機能で、ゾーンやリージョンといったラベルごとにストレージをグループ化してアクセスを制御することに利用できる。これはストレージだけではなくサービスにも設定可能で、ルーティングなどにも利用できるようだ。

Cephの概要を紹介

今回はKubernetesクラスターのストレージとしてCephを使用するということで、分散ストレージとしての概要を解説。ここではクラスター内で分散するために必要な要素として、MonitorとObject Storage Device（以下、OSD）を紹介した。ここで簡単に触れられているPaxosは、複数のノードをマスター／スレーブとして固定せずに「マスター」に相当するノードが故障したような場合にも、他のノードが「マスター」として入れ替わり、稼働し続けるための分散合意のためのアルゴリズムで、分散処理で必須の仕組みである。

CephのMonitorをラックに1台構成したい時はAnti-Affinityを使う

次に例としてサーバーラックに格納された複数のサーバーにおいてCephのMonitorを配置する際に負荷や障害対応を考慮して1ラックに1Monitorという構成を取ろうとする場合、KubernetesではAnti-Affinityを利用することでスケジュールすることが可能であることを解説した。

Rookの紹介

次にRookの概要を紹介。RookはCephをKubernetesから利用するためのソフトウェアで、CNCFのインキュベーションプロジェクトだったが、2020年10月にGraduationステータスに達して、十分に成熟したソフトウェアであるという認証を得たプロジェクトだ。

サイボウズが解決したい問題

今回のセッションではサイボウズが解決したい問題として「LVMを使うことでCeph以外にストレージを使えるようにすること」「分散ストレージであるCephを状況に応じて最適に配置すること」の2点を挙げた。

LVMを使ってストレージを柔軟に使いたい

最初の問題は、複数のサーバーに存在するストレージをCephだけではなくMySQLなどの用途にも使えるようにボリュームを切り分けたいという要望だ。そのためにTopoLVMというKubernetesのCSIプラグインを開発したという。

CSIプラグインであるTopoLVMとRookを組み合わせてボリュームを切り出す

この方式では、ユーザーからのボリュームリクエストであるYAMLファイルの定義に従ってRookがOSDをアタッチするPodとPersistentVolumeClaim（以下、PVC）を作成、それに物理的なボリュームであるPVを割り当てるのではなく、PVCからのリクエストをTopoLVMが受け、動的に論理的なボリュームを割り当て、それをPVとしてPodにアサインするやり方になる。

動的にLogical VolumeをOSDとして提供

OSDの配置問題はPodの配置を先に決めることで解決

そして2番目の「CephのストレージであるOSDを最適に配置する問題」に対する解決案として、PersistentVolumeを直接Kubernetesから配置するのではなく、PVがアタッチされるPodを配置する問題として解決するという方法が紹介された。Podと同時にPVを生成するのではなく、Podを生成してから条件に適したPVをアサインする方法となる。

Podを先にスケジューリングしてからPVを配置

そしてこの配置問題に関連して出てきたのが、OSDをノード内に複数配置して最適化したいというニーズだ。

OSDを分散配置するためにはpod topology spread constraintsを使う

Kubernetes 1.18でベータとなったこの機能に存在するパラメーターのWhenUnsatisfiableでは、想定した動作をしてくれないため、OSDの分散配置は偏った形になってしまったと解説した。

新しいパラメーターが動けば最適な分散配置ができたはず

ノード間でアンバランスなOSDの配置となってしまった

想定と異なる動作という結果となったが、この機能を実装したメンテナーとの対話では「これが仕様通り」という回答が返ってきたという。

メンテナーは動作が仕様という回答

これに対して森本氏は Kube-Schedulerをチューニングして回避したことを解説した。

Kube-Schedulerの設定を変えて回避

これらのユースケースを通じて、サイボウズがRookに対して追加した機能を示したのが次のスライドだ。

サイボウズがRookコミュニティに機能追加を提供

最後にまとめとして、動的にOSDを配置できるTopoLVM、Kubernetesの新機能を使って分散配置を実装、同時にコミュニティに対しても働きかけて必要と思われる機能を貢献したことなどが挙げられた。

セッションのまとめ

とかく難しいと言われるKubernetesのPV問題だが、CSIプラグインの開発やメンテナーとの対話を通じて機能追加を行うなど、サイボウズのSREチームの積極的な姿勢が良く分かったセッションとなった。またKubernetesを利用する際には、ストレージの運用管理についてもKubernetesの流儀が必要となることをあらためて確認できたセッションでもあった。