2017年10月5日

ブロードバンドタワーで Scality RING を担当している、ポールです。
今回のブログ記事は、最近実験を行った、RING を動かしているサーバの OS を1台ずつバージョンアップして全体を入れ替えていく、という試みについてです。

CentOS 入れ替えの実験環境
CentOS 入れ替えの実験環境

結論を最初に書くのですが、その試みは実現可能であることが確認できました。用意した実験環境は、Supervisor が1台、NFS コネクタが2台、ストレージサーバが6台、合計9台の CentOS 6 が動作している RING 6 環境でしたが、これらを1台ずつ CentOS 7 で作り直して元の RING 6 環境に戻していきました。すべての OS バージョンアップが終わるまでは CentOS 6 と CentOS 7 が混合した RING 環境になります。全体のバージョンアップにはかなりの時間を要しましたが、予想に反して「無難に」実施できました。

・・・「無難に」と書いていますが、これは、どうやっても乗り越えられない困難はとりあえずなかった、という意味合いです。注意点はありますので、その中からいくつかご紹介します。

    • 作業の実態は、バージョンアップというよりも OS の入れ替えです。

CentOS 7 インストーラにバージョンアップの機能があったとしても、今回は使っていません。CentOS 7 をゼロからインストールして、1台ずつ再構成しています。というのも、仮に CentOS だけ都合よくバージョンアップできたとしても、RING を構成するパッケージまで CentOS 7 用のパッケージに入れ替えられるわけではないためです。

    • Supervisor については、上書きではなく別のマシンを用意する

Supervisor は通常1台しか存在しませんので、OSを上書きでインストールしてしまうと構成ファイルの退避に漏れがあった場合にファイルを取り戻せません。このため手順が確立するまでの間は、別のマシンを用意して OS インストールを行い、再構成することをお勧めします(仮想マシン環境ならば、別の仮想マシンを用意するのは容易だと思います)。逆にコネクタやストレージサーバは複数台で構成されていると思いますので、何か不慮の事故があっても同じ役割のサーバから構成ファイルを取り出して書き換えることで回避できます。

    • サーバごとの RING 構成ファイルをサーバの外に退避する

RING 6 からは scality-backup という機能があり、構成ファイルを日次でバックアップしています。ただしこのバックアップはサーバ内に生成されてしまうので、そのままでは OS 再インストール時に消失しますから、外部に退避する必要があります。OS バージョンに依存した構成ファイルは基本的にはないため、CentOS 7 で OS を再インストールし、CentOS 7 用のパッケージを再インストールした後に、バックアップからCentOS 6 時代の構成ファイルを戻してサービスを再起動すれば、RING 関連プログラムは元通り動作します。加えて、手間を減らすという観点では SaltStack 関連の設定ファイルにはサーバごとの鍵情報が含まれているため、同様に退避しておくとよいでしょう。

    • 各サーバごとの構成ファイルを RING 内に退避する場合は、コネクタを複数用意する

RING 環境にコネクタを1つしか用意していない場合、そのコネクタの再構成中には RING へのアクセスが不可能になります。このため、構成ファイルを RING 内に NFS などで退避していた場合、コネクタが動作していなければ退避した構成ファイルにアクセスできなくなるため、再構成が終わりません。もちろん後からコネクタを追加することもできますが、コネクタは事前に複数用意しておきましょう。

    • ストレージサーバの OS再インストール時に RING の実データが入ったドライブをフォーマットしない

これは、再セットアップが終わったストレージサーバのデータに関する balance や rebuild のメンテナンスを最小限にするために重要です。ファイルシステムの互換性さえクリアしていればデータは再利用できますので、既に大容量のデータを RING に保存している場合、データを消さないほうがよいです。

    • OS 再インストール後に生成された /etc/fstab を退避する(ストレージサーバのみ)

ストレージサーバで動作する biziod は物理ドライブへの I/O だけでなく、物理ドライブのマウント処理も担当するため、構成ファイルのバックアップには /etc/fstab が含まれています。構成ファイルのリストアを行う際に、OS 再インストール前の /etc/fstab を上書きしてしまうと、/ (ルート)パーティション等の記述で用いられるファイルシステムの UUID が変わっているため、そのままでは OS が再起動してこなくなるという悲劇が訪れます。レスキューモード等でこの問題に対処するのは残念なだけですから、ここは注意してください。

    • ストレージサーバのOSを再インストールする前に ZooKeeper, Elasticsearch の動作状況を確認する

RING 6 から、SVSD(Scality Virtual Server Daemon)や Folder Scale-out 機能で利用する Apache ZooKeeper や、Grafana が参照する統計情報のリポジトリである Elasticsearch のクラスタが、それぞれストレージサーバ上で動作しています。ストレージサーバの OS 再インストール後に、他のサーバ上で動作しているクラスタメンバと正しく同期がとれていないと、OS 再インストールが1台ずつ進むごとにクラスタメンバが減っていくため、どこかでクラスタとして動作できなくなる、という笑えない現象が発生します。私は SVSD の動作がおかしくなった時点で ZooKeeper のクラスタメンバが減っていたことに気が付きましたが、クラスタメンバが1,2台減った程度ではそれぞれのクラスタが普通に動作してしまうため、潜んでいる問題に気が付きにくいという落とし穴があります。なお、それぞれのクラスタの動作状況を調べる方法はインターネットで検索してみてください。

さて、この試みが成功したことから、何が実現できるのかを考えてみます。
IT システムを使い続けるうえで課題になるものの1つは、各コンポーネントの更新期限でしょう。更新がなくなる手前でバージョンアップやリプレースを検討することになりますが、Linux ディストリビューションについても例外ではありません。CentOS/RHEL 5系については既に2017年の前半で更新期限を迎えており、徐々に稼働するサーバが減っていくものと思います。 CentOS/RHEL 6 は更新期限が 2020年、CentOS/RHEL 7 は 2024年に設定されています。現時点でまだ数年ありますが、いつかは利用を止めるべき時がきます。今のところ RING は CentOS/RHEL の 6 と 7 両方に対応していますから、サーバを1台ずつ OS バージョンアップしていくことで、緩やかに更新期限をクリアできるのではないかと考えています。加えて、その途中で RING 自体のバージョンアップが必要になるタイミングも当然ありますから、RING のバージョンアップを OS のバージョンアップと時期を合わせるか、時期をずらして行うかが選択できます。バージョンアップは OS も RING も一大事ですし、個々のユーザごとに考え方や事情が異なると思いますので、ユーザに応じた何らかの方向性を緩やかに見出して提案できるのではないか、と考えています。

今回のブログ記事は以上になります。参考になりましたでしょうか。
今後も Scality RING に関連する技術内容を書いていきますので、ご期待ください。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。

投稿者: ポール

ブロードバンドタワーで Scality RING を担当。ストレージ業界の知り合いからはポールと呼ばれているが、本人も由来はよくわからない。得意領域はデータベースとストレージ。