HPCI 共用ストレージ運用改善のための技術移転
金山 秀智 1), 近藤晃 1), 原田 浩 1)

平川 学 1), 芝野 千尋 1), 尾崎 耕一郎 1)
1) 理化学研究所 計算科学研究機構
hidetomo.kaneyama@riken.jp
概 要 ：AICS の HPCI 運用では、運用改善として作業手順書・スキルマップ管理を実施してきた。さらなる運用品質向上のために構成管理ツール Ansible を導入し、構成管理と運用業務の自動化・機械化を行い、ヒューマンエラーの排除・定型業務の簡素化を実施した。また、Ansible を利用したドキュメント管理と技術移転のためのトレーニングの結果を報告する。

1 はじめに

バ 2 台、ファイルサーバ 16 台、ログインノード

理化学研究所 計算科学研究機構(以下、AICS)

10 台で構成されているため、複数のホストに対しの HPCI 共用ストレージ運用改善のため、定型・定ての更新を、正しく・短時間で実施する必要があ

例業務の作業手順書作成、スキルマップ管理などる。また、メンテナンス等で実施するプロセス停に取り組んできた。これらによって運用に必要な止・起動、動作確認等の定型業務についても、短情報が蓄積され、手順の更新と技術移転が進み運時間で実施しサービスのダウンタイムを短くする用担当者の負担が減少した。さらに運用品質の向ことが求められる。

上のため、業務の自動化・機械化、ひいては効率HPCI 共用ストレージの運用にあたり、定型・定的な技術移転を目指して構成管理ツールを導入し、例業務、障害対応に関してローカルドキュメント定型業務のトレーニングを試みた。構成管理ツーとしての作業手順書、障害対応指針などを作成し、ルの選定と導入、導入によって得られた運用品質運用品質改善をはかってきた。さらに、作業手順改善効果と問題点について報告する。

書の操作内容を自動化・機械化することにより、ヒューマンエラーによる誤操作の排除、定型業務の実施手順の削減を目的として構成管理ツールを導入することとした。
導入にあたっては、以下の観点から Ansible を採用し、運用チーム内での利用促進、技術移転に努める事とした。
・ 既存の運用向けスクリプトが再利用可能
・ 管理対象へのパッケージ設定・追加が不要
・ 導入に追加サーバ等の資源が不要
・ ネットワーク設定・構成変更が不要

図 1: ス キ ル マ ッ プ

・ プッシュベースで利用可能
・ 記述形式が YAML であるため、コード可読性が2 構成管理ツールの導入
AICS の HPCI 共用ストレージはメタデータサー

高い・ ドキュメントが充実している

・ 構成管理に加えて、プロセスの起動・停止、動作確認等の運用業務に利用可能
特に選定にあたっては、HPCI 共用ストレージがす

これにより、確実なサービスの起動・停止をAnsible のコマンド起動だけで実施できるようになり、実施手順が削減された。

でに実運用段階にあり 70 課題に利用されている(s n i p )現状を鑑み、以下を重要視した。

- s h e l l : " { { G F S D _ I N I T _ F I L E } } s t a t u s > / d e v / n ul l ; e c h o $ ? "regi ster: r esult

・ 既存の運用向けスクリプトが再利用可能
・ 管理対象へのパッケージ設定・追加が不要
・ 導入に追加サーバ等の資源が不要- shel l: "ps -ef | grep [ /]usr/l ocal/gf arm/sbi n/gfsd | grep{{ G FSD_HOS TNAME } } >/dev /null;e cho $? "regi ster: p s_resul twhen : resu lt.stdo ut == ' 1'
- shel l: "kil lall gf sd"

・ ネットワーク設定・構成変更が不要

igno re_erro rs: yes
when : ps_re sult.st dout == '0'

我々は Ansible の導入として HPCI 共用ストレージ

regi ster: k illall_ result

サービスの起動と停止及びその確認等の定型業務-を自動化し、チーム内メンバに技術移転を目的と(sni p)

したトレーニングを実施し構成管理ツールの導入

f a i l : m s g = " プ ロ セ ス ( g f s d )の k i l l a l l の 実 行 に 失 敗 し まし た "w h e n : ( p s _ r e s u l t . s t d o u t = = ' 0 ' ) a n d ( k i l l a l l_ r e s u l t | f a i l e d )図 3: gfsd 起動 確認

効果を検証した。

4 ドキュメントの二重管理の解消
実施手順が削減され、運用品質の向上に寄与した事は確かであるが、既存の作業手順書に加えてAnsible による実施手順の解説も必要となり、実施手順に関するドキュメントの二重化が発生した。
構成管理または定型作業を自動化した 16 項目に加えて、今後も増加する自動化項目のドキュメントを全て二重化して管理するのは困難である。また、技術移転では、複数のドキュメントを参照す

図 2: 構 成 管 理 ツ ー ル Ansible 導 入

ることとなり、受講者に負担を強いることになる。
このため、Ansible の Playbook に作業内容を直接3 HPCI 共用ストレージサービス定型業務の自動化記載し、構成記述と構成管理の実施動作を 1 つのドキュメントに統合することとした。

HPCI 共用ストレージ関連サーバのパッケージや設定ファイルの構成管理に加え、次のような定型業務を Ansible で自動化した。
・ サービスの起動・停止
・ サービスの動作確認
・ ReadOnly 設定/解除
・ motd によるメンテナンスアナウンス
例えば、サービスの起動・停止の場合、自動化の実装にあたっては、Ansible の Playbook や Role等の構成記述ファイルに以下のような記述を行い、デーモンプロセスの起動・停止だけでなく、その確認作業を自動化する実装とした。

図 4: 運 用 ド キ ュ メ ン ト 統 合

- hosts: FILESERVER% ./bin/ansibledoc.sh -f shared-storage_server-gfsd_service-ps_start.yml

sudo: yes

#Ansible-Playbook: shared-storage_server-gfsd_service-ps_start.yml

roles:====== 概要 ======- { role: gfsd-check, GFSD_PS_STATE: False }

gfsdを起動する。

- { role: gfsd-start }====== 仕様 ======- { role: gfsd-check, GFSD_PS_STATE: True }Gfarmのストレージサーバにおいて、gfsdデーモンを起動する。
前提条件: ストレージサーバにおいて、ディスク領域がマウントされていること。
: ストレージサーバにおいて、gfsdが起動していないこと。

図 5: 統合 前の Playbook実行対象: Gfarmのストレージサーバ
入力

: 無し。

結果

: gfsdデーモン起動の成功/失敗。

#OVV# gfsdを起動する。

結果確認: /etc/init.d/gfsd statusコマンドによるgfsdの起動確認。

#SFC# Gfarmのストレージサーバにおいて、gfsdデーモンを起動する。

====== 変数 ======#SFC# 前提条件: ストレージサーバにおいて、ディスク領域がマウントされていること。

GFSD_INIT_FILE: 起動ファイル名のフルパス#SFC#GFSD_PS_STATE: 状態確認時のステータス判定用のフラグ(False/Trueで停止/起動を切り替: ストレージサーバにおいて、gfsdが起動していないこと。

#SFC# 実行対象: Gfarmのストレージサーバ

え)#SFC# 入力

: 無し。

====== 実行内容(詳細) ======#SFC# 結果

: gfsdデーモン起動の成功/失敗。

1. gfsdのinitスクリプトから、gfsdのオプションを取得し、gfsdに設定されているカノニカ#SFC# 結果確認: /etc/init.d/gfsd statusコマンドによるgfsdの起動確認。

ルなホスト名を取得#DCV# GFSD_INIT_FILE: 起動ファイル名のフルパス

1.1.

initファイルからgfsdのオプションを取得$ cat {{ GFSD_INIT_FILE }} | grep esci-wgfs | egrep "/gf[0-9]#DCV# GFSD_PS_STATE: 状態確認時のステータス判定用のフラグ(False/Trueで停止/起動を切り替え)(snip)- hosts: FILESERVER

6. gfsdのプロセスをチェックする

sudo: yes
vars:
roles:

6.1.

プロセスが存在するか確認$ {{ GFSD_INIT_FILE }} status >/dev/null;echo $?

(snip)- { role: shared-storage/server/gfsd/common/set-fact, GFSD_INIT_FILE:/etc/init.d/gfsd }- { role: shared-storage/server/gfsd/common/check/mount }- { role: shared-storage/server/gfsd/service-ps/check, GFSD_INIT_FILE:

図 7: 生成 したド キュメ ント/etc/init.d/gfsd, GFSD_PS_STATE: False }- { role: shared-storage/server/gfsd/service-ps/start, GFSD_INIT_FILE:/etc/init.d/gfsd }- { role: shared-storage/server/gfsd/service-ps/check, GFSD_INIT_FILE:/etc/init.d/gfsd, GFSD_PS_STATE: True }5 技術移転トレーニング
HPCI 共用ストレージの運用は、高負荷かつ他機

図 6: 統合 後の Playbook

関との協調作業が多く発生するため、複数の運用ドキュメントの統合は、Ansible の Playbook とメンバを確保する必要がある。このため、技術移Role に、「#」と 3 文字キーワードのコメントを転トレーニングを行い、運用担当者以外の作業員記載することで実現した。コメントを記載した

へ HPCI 共用ストレージの定型業務の実施手順やPlaybook に対してドキュメント生成スクリプトを運用ノウハウを身に着けることとした

実行することで、ドキュメントが出力される仕組2016 年 8 月に、Ansible を利用した第 1 回目のトみである。例えば Playbook に「#OVV」や「#SFC」レーニングを実施した。トレーニング項目は、メのキーワードと説明文を記載しておくと、「概要」

ンテナンス定例業務として実施する以下の 3 項目「仕様」として出力される。図 6 からドキュメンである。

トを生成したのが図 7 である。

・ gfsd プロセスの起動・停止

ドキュメントの追加をするにあたり、以下の 3 点

・ パッケージと Gfarm のアップデートを併せて実施した。

・ HPCI 共用ストレージサービスの動作確認

・Ansible コードのリファクタリング

トレーニングは以下の手順で実施した。

・Playbook、Role、ディレクトリの命名規則制定

1. トレーニング項目のドキュメント確認

・ディレクトリ階層数の制限規則制定

2. 不明点を運用担当者に質問

いずれも技術移転時のコードの難読化を防ぎ学習

3. テスト環境での Ansible 実行・結果確認効果を上げるためである。

4. 本番環境での Ansible 実行・結果確認

Ansible にドキュメントを統合し二重化を解消し本番環境での作業を確実なものにするため、またたことで管理コストは減少した。また、更新作業自動化されている内容を理解してもらうため、においてドキュメントとコードの更新がセットにAnsible 実行前に可能な限り疑問を解決する手順なることで、ドキュメントとコードの不一致が発とした。

生しなくなった。

今回のトレーニングでは、以下の効果があった。

・ トレーニング受講者からの質問内容が具体的
・ 本番環境でのトレーニング時間が短縮
・ トレーニング受講者からの改善案(Ansible のコード/ドキュメント双方)の提示
今後、トレーニング受講者からの意見により浮かび上がった以下の問題点について改善を試み、第2 回のトレーニングでは効果を確認する予定である。
・ 全てのエラー処理が網羅されておらず、対処手順が自動化・ドキュメント化されていない箇所がある
・ Ansible 実行時にしか読み込まれない変数があるため、ドキュメント生成時に変数が展開されない

6 まとめ
HPCI 共用ストレージの運用品質向上のために、構成管理ツールとして Ansible を導入し、実際の運用業務に用いた。さらに技術移転のためのトレーニングも実施した。構成管理に加え、サービスの起動・停止だけでなく確認作業も自動化されるなど、品質改善効果がみられたが、手順書の二重化など運用コストが増大する要素も見受けられた。
ドキュメントの二重化に対しては、構成記述ファイルに実施手順内容を盛り込むなどの工夫を行い、ドキュメントを統一して運用している。
今後の課題としては、アカウント管理や障害対応などのより複雑で実践的な運用業務に対しても構成管理ツールを導入し改善効果を検証する必要があげられる。
また積極的に技術移転トレーニングを実施し、さらなる品質向上、要員確保につなげるべく構成管理ツール自体の運用改善が求められる。
特に障害対応については、技術移転や自動化が後回しになっていたが、運用ドキュメントの充実により現象の切り分け・対処方法の手順化が進んだため、今後は Ansible による自動化と技術移転トレーニングを進める予定である。