手軽に使えるS3互換ストレージを求めて

最近のシステムはよくS3互換ストレージ(AWS S3と同様のAPIでアクセスできるストレージ)を要求する。用途としては、バックアップであったりファイルの保存先であったりと様々だ。

自宅で動かしているシステムでも以下のようなコンポーネントがS3互換ストレージを使ったりする。

Prometheus
Grafana Loki
CloudNative PG
NextCloud
Hashicorp Vault
GitLab

S3互換ストレージが必須であったり、オプションであったり様々だが、手元で動かしているシステムでもこれだけのS3互換のストレージを利用するものがある。

なぜ広くS3互換ストレージが採用されているかというと、S3互換ストレージはアプリケーション側からは便利なストレージだからだろう。HTTP/HTTPS通信でファイルの保存を実行でき、本家のS3であればそれをそのまま外部公開まですることが出来る。複数のアプリケーションから同時に読み書きすることも可能だ。似たようなことを実現するものとしてNFSやCIFSといったものがあるがS3ほど手ごろではない。

S3互換ストレージはAWS、Azure、Google Cloudなどのパブリッククラウドでは提供されている。パブリッククラウド上のこれらのストレージは可用性も高く、費用も控えめになっているため利用できるなら利用すべきだろう。

一方でパブリッククラウドが利用できない環境では自前で環境を構築する必要がある。この記事は自宅に導入するものはどれにしようかと考えて検討した記録である。なお、商用のSANなどを導入している場合はそちらにS3互換ストレージの機能が提供されていることが多いのでそちらを検討するのが良いだろう。

候補

OSSでS3互換のストレージとなりそうなものは以下のものがある。これはGoogle検索やRedditなどの記事をいくつか読んで調べたものになる。

前提

家庭用なので小規模で、手軽に運用できるものが望ましい。以下のような感じである。

kubernetes上で動作させたい
規模としては1台-3台程度のクラスタ
運用負荷が高いものは採用したくない
故障はそれなりに発生して、たまにノードの交換もあったりする

特にノードの故障や動かしているシステムが動作不良になることはそれなりにある。OSが起動しなくなったがストレージはまだ読むことが可能でデータのサルベージをして新しい計算機で復旧させるというような状況は数年に1度は発生するものとする。

minio

Google検索を行うと事例が多いのがこのminioだろう。サーバサイドの暗号化やBucketの公開の機能などもありS3互換ストレージとしては申し分ない。

ただ、minioを運用しようとするのはあまり楽ではなさそうに見える。特にストレージの管理についてはminioはかなり大規模なシステムを想定していそうである。

minio自体のマニュアルによるとストレージの想定としては、排他的なアクセスになっていて、reclaimPolicyとしてRetainが設定されているStorageClassのPersistentVolumeであれば良いと記載がある。これはそれなりに設定されているkubernetesであれば実現可能である。

ただ、Direct Attached Storageを利用できる場合は DirectPV というCSI driverを導入してストレージの管理もminioに任せる方法を推奨している。つまり、minioに専用のストレージ(SSDなりHDDなり)を割り当てるようなことをminioとしては想定しているということだろう。

また、バックアップなどについてはマニュアルを探しても記載がなく Replication の項目にDisaster Recoveryなどについて記載があることから、BucketのReplicationを行ってバックアップ相当のものを作るということのようだ。自宅の環境としてこれを実現しようとすると、minioのバックアップのためにminioを立てるということになる。大変厳しい気持ちになる。

また、minioは保存する際にファイルの中身を分割して保持したりするため、minioが動作しなくなった場合にBucketに保存したデータを読むことが出来なくなる。トラブルが発生してシステムが動かなくなった場合に備えてバックアップやアーカイブといったものを保存しているわけだが、そのバックアップデータを読むためにはシステム復旧をしなければならないという状況になりかねない。

minioを本番環境で運用している人はすごいと思いつつ、家で採用するには厳しいと考えてminioの導入は見送ることにした。ただし、消えて良いようなデータの保持には便利に利用できそうである。ライフサイクルの設定で一定期間経過後にデータを削除するといったことがminioでは手軽に実現できるためログデータの保存先としては検討の余地がある。

Swift

OpenstackプロジェクトでS3互換の機能を提供しているプロジェクトがSwift。世の中の事例も多く、このSwiftをベースにした製品もそれなりにあるので実績は十分だろう。

これは自分も運用していたことがあるが、構築が面倒なのである。rsyncの設定やringの設定など独特のものも含めてちゃんと運用できるようにするにはノウハウが必要となる。また、ファイル保存の形式がこれもまたファイル分割する形となっておりシステムが動作しなくなった場合の復旧が難しいものとなっている。

余談: QNAPのオブジェクトストレージ機能

OSSではないのだがQNAPのNASを自分は所有している。このQNAPにはQuObjectというS3互換ストレージの機能がついている。この機能は、普段NFSやCIFSをとしてアクセスできる領域をS3互換ストレージとしてアクセス可能にするものとなっている。つまりこのS3互換ストレージが機能しなくなっても、ファイルの読み書きはNFSやCIFSで可能である形でS3互換ストレージを提供しているものになる。

この機能がどう実現されているかと思って、NASにsshして色々眺めてみるとこの機能の実態はOpenstackのswiftで実現されているようだ。ただ、swiftの項目で書いた通りswiftは独自のファイル管理の仕組みを持っているはずなので、何か仕掛けがないとNFS、CIFSの領域と共有するような形で提供できないはずである。

設定を注意深く読んでいると、どうやらglusterfs用の拡張を使って実現しているようだ。このglusterfsの拡張ではファイルなどの管理はディレクトリ構造をそのまま返すような形で実現されているようなのでそれを利用しているようだ(このあたりのコードを読んでそう理解した)。QNAPのNASはglusterfsを特に利用しておらずローカルのファイルシステムにはext4を採用しているので、このディレクトリ構造をそのまま返すglusterfsの拡張の作りにだけ注目したのではないだろうか？

自分で同じような構成のものを作ることは不可能ではないだろうが手間が掛かる上に、QNAPは認証の部分などは独自の拡張を作って対応しているようだ。おそらくNASの認証の仕組みとSwiftの認証を統合できるようにしているのだろう。自分で色々構築し始めるとそういった部分は独自に対応することとなるため現実的ではなさそうである。

QNAPのこの作りには大変興味深かった。

Rook(Ceph)

RookはCephをkubernetes上で動作させてストレージの管理を行ってくれるものである。CSI driverも提供しておりkubernetes上で動作させるストレージ基盤としては広く採用されている。このCephにはファイルシステムをS3互換ストレージとして提供する機能もあり、Rook Cephでもそれを提供するための仕組みが用意されている。

このRook Cephを導入すれば色々な問題は解決しそうである。が、個人的にはS3互換ストレージのためにRook Cephを導入するのは避けたい。というのもS3互換ストレージのためだけに導入するにはRook Cephは保守の手間が掛かりすぎることが想像できるからである。

障害対策としてsnapshotを取っておくことやストレージのイメージを直接mountすることも可能そうである。ただ、障害が発生したノードを適切に復旧するのは苦労がありそうである。サイボウズさんの記事などを見ると導入には躊躇してしまう。

Google検索していると個人の方でもkubernetesでrook cephを採用している事例がちょこちょこあるのでぜひ障害対応のノウハウなど知見を公開して欲しい。

s3gw

これはlonghornと組み合わせることで、S3互換ストレージを提供することを目指しているプロジェクトのようだ。Rancherのkubernetesソリューションでは手軽に使えるようになっている(s3gwのquickstart)。longhornと組み合わせることを意図しているが、単にPersistentVolumeがあればどんなCSI driverとでも上手く動くようだ。Rancherの意図としては、longhornにreplicationなどを任せて、s3gwはそれをS3互換ストレージとして公開するようなイメージなのだろう

試しにdockerコンテナで動作させてみると

 docker run -e RGW_DEFAULT_USER_ACCESS_KEY="test" -e RGW_DEFAULT_USER_SECRET_KEY="test" -v ./bucket-test:/data  -p 7480:7480 quay.io/s3gw/s3gw:latest

手軽に起動できる。ただ、残念ながら保存する形式はファイルを分割して保存する形式のようだ。
簡単に起動できただけに惜しい…。

versitygw

通常のファイルシステムをS3互換ストレージとして公開するOSS製品のようだ。ScoutFSというファイルシステムを開発している会社が公開しているもののようだ。

自分の需要ととても一致してそうなOSSのようである。local-pathで作ったPersistentVolumeをこのversitygwで公開するような形にすれば、障害発生時にはローカルのファイルシステムを読めればデータの復旧が可能で、バックアップもそのローカルのファイルシステムのバックアップを随時行う形で実現可能である。

起動も簡単でgoのバイナリを配布しているのでそのまま起動すれば良い。コンテナ化

 ROOT_ACCESS_KEY="testuser" ROOT_SECRET_KEY="secret" ./versitygw --port :10000 posix /tmp/vgw

ただ残念なことに手元で試した範囲では応答速度が悪く、性能に懸念がある。

time aws --no-verify-ssl  --endpoint-url http://192.168.5.162:10000 s3 ls --profile versitygw
aws --no-verify-ssl --endpoint-url http://192.168.5.162:10000 s3 ls --profile  0.29s user 0.01s system 12% cpu 2.325 total

簡単なクエリを投げてみているだけなのに、2秒近く待たされる結果となっている。この原因が分かれば良いのだが惜しい感じである。

Garage

これはminioと同様のS3互換ストレージを提供するOSSである。minioよりも動かすのが手軽そうだが、minio、swift同様システムダウン時にファイルを読むのが苦労しそうなので、少しだけ調査して採用は見送った。

とりあえずの結論と運用の方針

自宅で動かすS3互換ストレージの最終候補

今回色々調べてみたが、とりあえずs3gwをもう少し検証しようと考えている。

Rancherが開発しているのでOSS自体の継続性も期待できる
デプロイが簡単
ファイルシステムそのままとは言わないが指定したディレクトリを保持できれば、別のところ(dockerなどで)比較的容易に再現環境が構築できそう

というあたりが自分には魅力的に見えている。

直接ファイルシステムを公開するような形になっているのが理想的だったのでversitygwの性能向上に期待したいところである。

s3gwはまだ若い製品でもあるようなので結局安定しているminioをどうにか使う道もあるのかもしれない。その場合のminioはSingle-Node Single-Drive構成を選びそうである。

加えてQNAPのS3互換ストレージなどを組み合わせればバックアップの定番の3-2-1の構成を取ることも実現できる。遠隔地をどこにするのかはまだ考えていないがpcloudが安いのでpcloudになりそうである。

運用上の課題

結局のところ、S3互換のストレージにデータを格納していたがそのストレージサービスが完全に故障してしまった場合にどのように復旧できるのか？というのに明確に回答を出しているサービスはほぼ存在していなかった。s3gwはlonghornを当てにしているからかとてもシンプルなつくりになっているので復旧の可能性を一番感じるがそれでも不安である。

結局rcloneやresticなどを使ってS3互換ストレージからNFSなどの旧来のストレージに定期的にバックアップするようなフローを組む未来が見える。S3などをバックアップ先として選んでいるシステムがいくつかあり、それのためにS3互換ストレージを準備しているのだが、そのS3互換のストレージを全く信用できないためこのような思考になっているのだが、世の人はどのように解決しているのだろうか。

システムがダウンしたときに簡単にはデータが読めなくなってしまうシステムとしてpostgresqlやmysqlといったDBMSがあるが、これらのシステムでは定期的なバックアップを取ることが必須となっている。S3互換のストレージも同様に運用するしかないのであろう。

余談2: もう少し規模が大きいオンプレ環境なら？

3-6台の規模の商用のサーバ群があって、それぞれのストレージがちゃんと(Raid6などで冗長化されている)のであれば、longhorn + s3gw か Rook Cephの採用を自分は検討しそうである。さらにどちらかというとlonghornを選ぶだろう。longhornを利用していたときに保守がとても楽だったからである。代わりに速度などはあまり出なかったので要件次第である。

SANの導入が完了していてdirectpvを使う目処が立っているならminioの採用を検討するかもしれない。なお、AWSのS3への接続が許されるように調整するのが一番なのは言うまでもない。

候補

前提