ファイルサーバのリプレース・サービス

ファイルサーバはHPCクラスタの基盤

HPCクラスタは計算機だけで構成されているわけではありません。ファイルサーバ、管理サーバ、スイッチ類などがあり重要な仕事をしています。そのなかでもファイルサーバは特に重要です。ファイルサーバはデータを保管するだけでなく、システム全体に共有ファイルシステムを提供する中枢として機能しています。HPCクラスタでは計算データのみならずアプリケーションそのそのもファイルサーバ側に搭載しておきます。そのためデータアクセスは各計算機の内蔵ディスクを使わずファイルサーバ側で行う仕組みになっています。ファイルサーバの負荷は外からは見えませんが、実際はシステムの背後で各計算機のファイルI/Oを集約し働いています。

ファイルサーバは安定稼動が大切

HPCクラスタは導入後から２～３年間は安定稼動が続きます。しかし３年も経つと、ハードディスクを多用するファイルサーバは回転部品の経時劣化により故障確率列が高くなることが心配になります。そこで「転ばぬ先の杖」として、万一の故障を回避するためのファイルサーバのリプレース (更新) プランが大切になります。

リプレースの理由

ファイルサーバのリプレース理由としては、下記のような点を挙げることができます。

・容量・性能不足解消のため上位機種へアップグレード
・バックアップ環境の構築 (新規サーバを導入、既存サーバはバックアップ用にリユース)
・ファイルサーバが経時変化で不安定になり、最新鋭機へ世代交代
・ファイルサーバの故障やサポート品質からリプレースを検討

リプレース作業は複雑

ファイルサーバのリプレースは、単に新設機を購入してネットワークに接続するだけではありません。リプレースは複雑なSE作業を必要とします。既存のファイルサーバからのデータの引継ぎと、ネットワークなどの各種設定の移行、開発環境などの整合性の確認、ジョブスケジューラなどのミドルウェア設定など。これらの要素を考慮して行わないと混乱を招きます。このような作業はプロにお任せください。

リプレースの方法をFS専用機とFS兼用機に分けて解説

このリプレース作業をFS専用とFS兼用機に分けて解説します。FS専用は主に中型以上のHPCクラスタで用いられるもので、別に管理サーバやアプリケーションサーバを備えているシステムに採用されるFSです。FS兼用機は小型HPCクラスタに多く採用されており、１台で管理サーバやアプリケーションサーバの役割も担っているシステムです。

ファイルサーバ専用機のリプレース

一般にPCクラスタには、ファイルサーバと管理サーバ (NIS、LSFのマスター、開発環境、ログインノード利用) が独立して実装されています。今回はこのファイルサーバ側のリプレースを考えます。これに対して管理サーバは、PCクラスタの処理の仕組みを担うため、設定されている内容の変更を嫌い、出来るだけ長期の運用が望ましいからです。

ファイルサーバ専用機リプレースの実際

それではファイルサーバのリプレース作業の実際を簡単にご紹介します。リプレースは下記の順序で行います。
1. 新設機に対しては最初に、未使用の仮ホスト名と空いている (異なる) IPアドレスを割り当て
2. 既存機から新設機へのデータのバックアップ (吸い上げ) をネットワーク経由で実行
3. データのバックアップ (吸い上げ) 完了後、データ容量とファイル/ディレクトリ数の比較を実行
4. 実際のファイルを参照し、オーナー/グループ/パーミッションのチェックを実施
5. 実際のファイルを用いてデータアクセスのサンプル確認を実施
6. 既存機の運用を停止する
7. 停止後、既存機のホスト名、IPアドレスを新設機に設定
8. HPCクラスタにファイルサーバとして組み込み最終テスト
9. 問題なければ通常運用の再開
10. 引退した旧サーバのホスト名、IPアドレスを書き換えて新設機との重複を避ける
11. 旧サーバはユーザー様の指示により、バックアップ用、テンポラリデータ用などの用途へ再設定

一般的にはこのような手順です。しかし、お客様の都合や運用状況によっては、5までの作業で留め、暫くの間はバックアップサーバとして運用しておきます。そして、タイミングを見計らって切り替えを行う場合もあります。

ファイルサーバ管理サーバ兼用機のリプレース

ファイルサーバと管理サーバは役割が異なります。そのため、ファイルサーバ管理サーバ兼用機をリプリースしようとすると、問題が起こる場合が多いです。このような場合には、管理サーバとファイルサーバを独立させる必要があります。この事情を理解していただくため以下に要点を整理してみました。参考にしてください。

1. 新設機によるMACアドレスの変更によるライセンス認証の問題

Intel CompilerのFloating License、PGIコンパイラのライセンス、商用アプリケーションのライセンスサーバ、LSFのライセンスなど、多くのライセンス認証ではMACアドレスを参照している場合が大半です。そのためサーバ本体の入れ替えに伴うMACアドレスの変更に応じてライセンス更新手続き作業が必要となります。ところがこのライセンス更新は、すぐ取得できないものや、手続きが煩雑なもの、費用が発生するものなどがあります。

2. 所内ネットワークへの接続許可

所内ネットワークとの接続ではMACアドレスにて接続申請を行う場合が多く、この更新手続きも必要です。

3. ゲートウェイサーバのセキュリティ設定

管理サーバに施してあるファイアーウォールの設定やログイン制限など、セキュリティー設定の引き継ぎと、新設機への再設定も作業量があります。このような設定は、ベンダーが行ったかお客様が行ったかに関わりなく複雑であることが多く、大きな負担を伴う作業です。

4. NISサーバ

ユーザ情報やパスワードの環境移行は不可能ではありませんが、作業量があります。

5. 開発環境

特にglibcなどのバージョンが異なったり、既存サーバが32bit環境であった場合には、新設機を管理サーバとしては利用できなくなります。

このような理由からファイルサーバと管理サーバの兼用機において、管理サーバ機能を新設機に移行することは困難です。そのため、ファイルサーバ機能のみのリプレースが基本となります。

1. ファイルサーバだけをリプレースする
2. 既存機のファイルサーバ機能を停止させる
3. 既設機の管理サーバ機能は継続運用できる設定とする

もし、既存のファイルサーバ管理サーバ兼用機が、動作不安定などの理由から運用を断念される場合もご相談に応じさせていただきます。

ファイルサーバ管理サーバ兼用機リプレースの実際

ファイルサーバ管理サーバ兼用機の場合は、ファイルサーバ専用機の場合と作業が少し異なります。作業が異なっている部分は、新設するファイルサーバには既設機と同じホスト名、IPアドレスを用いることができないので、異なるホスト名、IPアドレスを割り当てて使用するため、クライアントノードのNFSサーバの参照先の設定変更も最後に行う必要があるからです。

それではファイルサーバのリプレースの実際を簡単にご紹介することで、イメージを膨らませていただくことにします。リプレースは下記の順序で作業を行います。

1. 新設機に対しては最初に、未使用のホスト名と空いている (異なる) IPアドレスを割り当て
2. 既存機から新設機へのデータのバックアップ (吸い上げ) をネットワーク経由で実行
3. データのバックアップ (吸い上げ) 完了後、データ容量とファイル/ディレクトリ数の比較を実行
4. 実際のファイルを参照し、オーナー/グループ/パーミッションのチェックを実施
5. 実際のファイルを用いてデータアクセスのサンプル確認を実施
6. 既存機のファイルサーバとしての運用を停止する
7. 停止後、クライアントノードのNFSサーバの参照先の設定を変更
8. HPCクラスタにファイルサーバとして組み込み最終テスト
9. 問題なければ通常運用の再開
10. 旧サーバはユーザー様の指示により、バックアップ用、テンポラリデータ用などの用途へ再設定

一般的にはこのような手順で作業を行います。但し、お客様の都合や運用状況によっては、5までの作業を行い、その後も新設機は暫くの間はバックアップサーバとして運用し、タイミングを見計らって切り替えを行う場合があります。

入れ替えにより引退したファイルサーバの有効利用

ファイルサーバのリプレースでは、引退する既設のファイルサーバの処遇も大切です。引退したファイルサーバは状態にもよりますが、多くの場合はバックアップ用ファイルサーバとして継続利用したり、予備のファイルサーバとして万一に備えて待機させることができます。

さいごに

HPCクラスタの拡張は、生物の世代交代のようなイメージを伴います。その要となる作業がファイルサーバと管理サーバの更新です。単にハードウェアを持ってきて接続するだけでは作業は不十分です。このページでご紹介したような作業を正しく施さないと快適な環境として利用の再開にはなりません。そのために弊社では、安定したハードウェアの提供のみならず、HPCクラスタの運用に焦点を定めた高品質なシステムインテグレーションを提供し、お客様のPCクラスタの快適な運用に貢献いたします。