IBM 現場SEのITな日々

IBM現場SEが日々駆使している技術、現場SEの経験・知見を綴るブログです

(kin) AIXにおけるパスワードハッシュの作成方法

 AIXで色々なパスワードのハッシュの作成方法について書こうかと思う。単純に書くのであればコマンド1つ書いとけばいいのだが、まぁそれだと記事にならないので、その前提なども少々。
 まずはパスワードについての基本から。
 パスワードというものは基本的にシステム上に平文で保管されることは少ない、今となってはほぼないといってもよい。流出に対しての耐性を高めるため。パスワードは基本的にシステム内にハッシュ値として保管される。よく暗号化パスワードなどと表現されているが、基本パスワードとハッシュ値は1対1で且つ不可逆である。すなわちハッシュ値からパスワードを復号、もしくは演算することはできない。よって、パスワードハッシュが流出した場合、いわゆるプルートフォース(総当たり)によるパスワード解析にかけられることになる。そのため、パスワードのハッシュアルゴリズムはこの演算の際に如何に多くのCPUを使わせるかが重要となってくる。大量の演算により結果がでるまでの時間を非現実的にまで引き延ばすことでパスワード解析を事実上不可能にするのである。
 そのため、パスワードハッシュのアルゴリズムはCPUの進化と共に複雑にならざるをえない。当初Crype(3DES)しかなかったアルゴリズムMD5になりSHA2になっているのも、CPUの進化やレインボーテーブルなどの解析方法の進化により単純なアルゴリズムではパスワード解析が現実的になってしまったためである。現在ではSHA1までは既に危険とされSHA512もしくは精々がSHA256辺りまでが当たり前となっている。
 Linuxでは大分前からデフォルトがSHA512(type6)にかわっており、少し前まではツール類が追い付いておらずハッシュ計算に苦労したが、今では普通にcrypt関数でサポートしている。しかし、AIXでは何故か未だにデフォルトがCrypt(3DES)。非常に不思議だがMWとの関連などで仕方ないのだろうか? ちなみにWindowsも長い間LMハッシュが生きていたし、いまだNTハッシュ(MD4)が生きている辺り、独自実装の世界はこの辺りの進化が遅いような気がする。
 MW側での対応が遅いのは将にハッシュアルゴリズムの問題のように思う。表題のパスワードハッシュの作成方法とも絡むのだが、ユーザーの認証処理などを行う場合、UNIX系では割と入力されたパスワードを自分でハッシュ化するような実装が多かったように思う。今では大部分がMW経由だったりAPI経由だったりするため、ユーザーとパスワードをAPIなどに渡してOK/NGを判断しているのが大半かと思うが、そうではなく、入力されたパスワードをハッシュ化して、システムに保管されているパスワードハッシュと比較するのである。当時はその実装方法によるメリットは色々あったわけだが、ハッシュアルゴリズムが入れ替わる現在ではほぼ致命的である。アプリケーションが自身でハッシュアルゴリズムに対応する必要があるため、新しいアルゴリズムには中々対応できない。しかも独自実装。MW側の対応が中々進まないのも仕方ない気にはなる。

 ここまで基本的な話を書いてきたが、この辺りからが本番。
 まずは、パスワードハッシュの独自実装とは何のことか? これまで書いている通り、基本的なアルゴリズムは共通といってよい。SHA2にしろMD5にしろ公開されており同じものである。違うのはパスワードハッシュのフォーマットである。パスワードハッシュには必須の情報が幾つかある。ハッシュのアルゴリズムが何かと、ハッシュされた値と、ソルトである。
 ソルトとは文字通り、各個人の好みにより味つけを変えるための塩のこと、すなわちハッシュ値にバリエーションを持たすための乱数である。前記のようにパスワードとハッシュ値は1対1、ソルトがないと同じパスワードは同じハッシュ値となる。片方のパスワードを知って、別のユーザーのパスワードを推測できるようでは困るのである。そのため、パスワードハッシュを生成する場合は、パスワードと乱数のソルトを元にしてハッシュ値を計算することにより、同一のパスワードでも別のハッシュ値とするようにする。
 パスワードハッシュのフォーマットは元々全UNIXで共通であった。アルゴリズムが1つしかなかったため、必ず頭2桁がソルトで、残りがハッシュ値の13桁となっていた。しかし、様々なアルゴリズムが存在する現在、そのアルゴリズムを表すキーワードを何にするか?どのような順番にするか?などがシステムによって違うのである・・・というかAIXだけ違う・・・。

 Linuxの場合、パスワードハッシュのフォーマットは以下のようになる。

   $type$ソルト$ハッシュ値

 「$」が区切り文字で、最初がアルゴリズム、次がソルト、最後にハッシュ値である。例えばSHA512の場合、以下のようになる。ちなにみHP-HXもSolarisも同様。


   $6$1234567890123456$YfUD.j5zIFtfV6VgikPof2dzCCCZwL2YDraBX4HXi.J7iNq24667epYUCZGxExqOmHTnPWybzfYaynT29vKXJ/

 Type6がSHA512を表し、Type5はSHA256、Type1がMD5を表す。分かり易いようにソルトは全て並びの数字にしている。
 ではAIXはというと以下である。

   {ssha512}06$1234567890123456$/lorQE8P98Iw0lzrzOubFgMqe/p0tcWeC99jbL2KcWnK5jKcXx0WPYqo2aILdeH9Nrwg8A6p/InBnWiqBfWW..

 フォーマットもハッシュ値も全く違う。しかもこのフォーマットはアルゴリズムによって違う。SSHAの場合は以下のようなフォーマットとなる。

   {アルゴリズム}ストレッチング回数$ソルト$ハッシュ値

 ストレッチング回数とはハッシュを繰り返す回数のことで、前記のように、よりCPUを消費させることを目的にした実装である。ハッシュした値を更にハッシュし、この数分演算を繰り返すことで同一のアルゴリズムで数倍のCPU消費を強制することができる。ちなみにsmd5の場合、ストレッチング回数の指定はなく、ソルトは8桁となる。
 何故こんなに違うのかというとLPA(Loadable Password Algorithm)のせいである。LPAとは上記のようなパスワードハッシュのモジュールを独立させることで、システムに対してのアルゴリズムの追加、変更を容易にしようというもので、sshaをサポートするモジュールとsmd5をサポートするモジュールは全く別なのである。そうはいっても標準化しろよ、といいたくはあるが・・・
 様々なアルゴリズムが存在し、更に増えていくであろう現在、こんなにバラエティにとんだアルゴリズムをアプリ側で独自にサポートするのはさすがに無理がある。私自身、システム管理者として振出したパスワードの確認などでパスワードハッシュを作りたいと思うことが割とあるのだが、どうやって作ったものか悩んでいた。Linuxではフォーマットを標準化してcryptでもサポートしているが、AIXでもサポートしないかと思っていたら、サポートされていた。しかし、中々に情報がない上に、間違っていたり、不安定だったり・・・未だ不明な部分も多いのだが、ちょっと情報公開しておこうかと思った所以である。
 crypt関数はAIXの提供するC言語のライブラリ関数である。非常に伝統的な関数であり、元々は引数にパスワードと2桁のソルトを指定すると13桁の3DESのハッシュ値を返してくれるものであった。それが、LPAのその他の様々なアルゴリズムをサポートするようになったのである。とはいえ、それだけでは余り嬉しくはない。プログラムを書くのはいいのだが、様々な環境やシステムを弄る立場上、どこでコンパイルしたらいい? という問題が常に付きまとう。もっとどこででも簡単にと思っていたら、あった。perlである。perlにはシステムのAPIそのままの関数が様々にある。cryptも伝統的な関数なのでperlでもサポートされ、以前はよく使っていた。恐らくはそのままシステムのAPIを呼び出しているだけと思われたので、ためしにC言語のcrypt関数と同様のソルトを指定してみたところ、サポートされていた。
 perlでcrytを使う場合の基本的な使い方は以下の通り。ほんの1行、スクリプトにするまでもない。
 
   # perl -e '$hash=crypt("password","salt"); print "$hash\n";'
   sa3tHJ3/KuYvI


 デフォルトの挙動では3DESの13桁のパスワードハッシュが生成される。
では、ssha512の場合はどうなるか?

   # perl -e '$hash=crypt("password","{ssha512}06\$1234567890123456\$"); print "$hash\n";'
   {ssha512}06$1234567890123456$/lorQE8P98Iw0lzrzOubFgMqe/p0tcWeC99jbL2KcWnK5jKcXx0WPYqo2aILdeH9Nrwg8A6p/InBnWiqBfWW..


 みごとにssha512のパスワードハッシュが生成された。上記で「$」の前に「\」があるのは「"」で囲っているためエスケープしてやる必要があるためである。
ちなみにここでソルトを省略した場合、乱数のソルトを自動で生成してくれる。

   # perl -e '$hash=crypt("password","{ssha512}06\$"); print "$hash\n";'
   {ssha512}06$sL.WSbJpW2xdD2G5$FrvXYETBde5oGMkSc9VWSNwmPaLkitpGUlYf5pcKRNmM3a8aDbCKk9dtf83qBs2GrKQzbUjytXXIODNWgy.s..


 ここで指定できるアルゴリズムは以下のファイルに指定されている。

   /etc/security/pwdalg.cfg

 ここまでは綺麗に動いているようにみえるが、何が不安定なのか?

 LPAの弊害なのか、元々のcryptの仕様の問題なのか、バグなのか、全てのフォーマットエラーを無視して伝統的なcryptとして動くのである。例えばストレッチング回数。サポートされるのは4-31回だが、4回と指定してみる。

   # perl -e '$hash=crypt("password","{ssha512}4\$01234567890123456\$"); print "$hash\n";'
   ZOb9qQRD8CKi6


 なぜか13桁のパスワードハッシュが返る。これだけ見ると全くLPAをサポートしているようには見えない。しかし「4」ではなく「04」と指定すると。

   # perl -e '$hash=crypt("password","{ssha512}04\$01234567890123456\$"); print "$hash\n";'   {ssha512}04$01234567890123456$3OUe2I2xLl/nokoAYMBZG.Pprz3b/NZEVk21.mdzRyIOfCPWO56wXdFUFmKMidl.X5ZOsmqXhKOBjH6w8mmG..


 きれいにssha512のパスワードハッシュが返ってくる。また、cryptのマニュアルを見るとアルゴリズムに{SMD5}を指定できると記述されているので、{SMD5}を指定してみると。

   # perl -e '$hash=crypt("password","{SMD5}012345678\$"); print "$hash\n";'
   sa3tHJ3/KuYvI


 13桁のパスワードハッシュとなる。正しくは/etc/pwdalg.cfgの記述の通り、{smd5}。

   # perl -e '$hash=crypt("password","{smd5}012345678\$"); print "$hash\n";'
   {smd5}012345678$7nAzsz9W7rm48taUp/QYt.


 基本的にエラーは返してくれず、NULLにさえならない、間違っていると13桁になるだけ。この辺りの挙動は本当に困った。最初にマニュアルから入っていたため、純粋にサポートされていないようにしか見えなかった。しかも一般ユーザーで実行すると、全て13桁のパスワードハッシュに・・・

   $ perl -e '$hash=crypt("password","{ssha512}04\$01234567890123456\$"); print "$hash\n";'
   JQMuyS6H.AGMo


 AIXのcryptでLPAを利用する場合の注意点は以下の通り。

   ①rootで実行する
   ②指定できるアルゴリズムは/etc/security/pwdalg.cfgと正しく一致させる
   ③ストレッチング回数は2桁で指定する
   ④エラーは返してくれない。

 

 この辺りに気をつけて使えば非常に便利だと思う。
 ちなみにlinuxperlでも普通にcryptはサポートされているので、同様にソルトを指定することでType6などのパスワードハッシュを生成できる。但し、ソルトの自動生成はサポートしないようだ。

(鈴木)xCAT管理ノードのインストール手順

鈴木です。
前回に続き、今回は、xCATのインストール手順について紹介していきます。

6h324.hatenablog.com
基本的には以下のリンクのとおりなのですが、とっつきにく部分があったり、そもそも英語は読みたくないって方も多いかと思います。

http://xcat-docs.readthedocs.io/en/stable/

そこで本記事では、事前準備からインストール後の初期動作確認までを日本語で紹介するので、興味のある方はぜひトレースしてみてください。

1.本環境の概要

まずは今回のシステム環境について。
今回はxCATのコマンドを発行する「xCAT管理ノード」がインターネットに接続されていない前提で話を進めます。
「xCAT管理ノード」は、インターネットに接続されていないため、xCATインストールモジュールは別途用意するリポジトリサーバ経由でインストールすることにします。

f:id:users-6h324:20170728095113j:plain

また、今回紹介する記事では以下のHW, SW構成で話を進めます。

f:id:users-6h324:20170728094830p:plain

2.リポジトリサーバ準備

今回は、サーバがインターネットに接続されていないケースを想定しているので、xCATモジュール置き場としてリポジトリサーバを準備します。
リポジトリサーバを別途立てるのは面倒くさい、という場合は、xCAT管理ノードと同一OS上に構成しても問題ありません)
まずは、リポジトリサーバに必要なパッケージをインストールするために、リポジトリサーバ自身(ホスト名:repo01)でyumが使えるようにしておきます。
今回は、RHEL7.2のOSイメージを、/nim/RHEL_7.2/Server配下にコピーしておきます。

RHEL7.2用リポジトリファイルを作成
[root@repo01 ~]# vi /etc/yum.repos.d/server.repo
[Server]
name=RHEL7_Base
baseurl=file:///nim/RHEL_7.2/Server
enabled=1


[root@repo01 ~]# ls /etc/yum.repos.d
rhel-source.repo server.repo

リポジトリを初期化
[root@repo01 ~]# yum clean all

これでリポジトリサーバ自身(ホスト名:repo01)でyumを使ってRHEL7.2 OSパッケージをインストールできるようになります。
さっそく、リポジトリサーバに必要なパッケージを以下のとおりインストールしていきます。

[root@repo01 ~]# yum install createrepo

[root@repo01 ~]# yum install httpd

再起動時にhttpd自動起動するように設定しておきましょう。
[root@repo01 ~]# systemctl enable httpd

httpdを起動します。
[root@repo01 ~]# systemctl start httpd

念のため、リポジトリサーバ(ホスト名:repo01)と同じNWセグメントからブラウザ上で以下のURLにアクセスできるか確認しておきましょう。

http://リポジトリサーバのIPアドレス/

 

Apacheのデフォルトの公開ディレクトリは「/var/www/html/」なので、xCATインストールモジュール配置用に以下のようなディレクトリを作っておきます。

/var/www/html/yum/x86_64/xCAT

改めて、以下のURLにアクセスすると公開ディレクトリが見えるようになっています。

http://リポジトリサーバのIPアドレス/yum/

 

f:id:users-6h324:20170728111023p:plain

次に以下のサイトでダウンロードしておいたxCATのインストールモジュールを先ほど作っておいた/var/www/html/yum/x86_64/xCATに配置しましょう。

(DLサイトトップ)
https://xcat.org/download.html

[root@repo01 xCAT]# ls -ltr
total 8
drwxrwxr-x 16 root root 4096 Mar 16 01:50 xcat-dep
drwxrwxr-x  2 root root 4096 Mar 16 01:50 xcat-core

ついでに、最初に使った/nim/RHEL_7.2/Server配下のOSイメージも、公開ディレクトリに置いておくと他サーバからもyum installできるようになるので便利です。
私の場合は、/nim/RHEL_7.2/Server配下のOSイメージを/var/www/html/yum/x86_64/RHEL72配下にコピーしておきました。


rpmパッケージが配置されているディレクトリ上にリポジトリファイルがない場合はyum install時失敗してしまうので、createrepoしておきましょう。

(例)
[root@repo01 ~]# createrepo --simple-md-filenames /var/www/html/yum/x86_64/RHEL72

3.xCAT管理ノード準備

リポジトリサーバの準備が整ったので、さっそくxCAT管理ノード(ホスト名:xcat01)上でxCATインストールしていきます。

まずは事前準備としてリポジトリの設定を行います。
今回は、リポジトリサーバ上のRHEL7.2のOSパッケージ、xcat-core、xcat-depに対してyum installできるように設定しておきます。

RHEL7.2 OSパッケージ用リポジトリ定義

[root@repo01 ~]# vi /etc/yum.repos.d/server.repo
[Server]
name=RHEL7_Base
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/RHEL72/Server
gpgcheck=0
enabled=1

 xcat-core、xcat-depに対してもyum installできるように以下のようにリポジトリ定義しておきます。

[root@xcat01 ~]# vi /etc/yum.repos.d/xcat2core.repo
[xcat-2-core]
name=xCAT 2 Core packages
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/xcat-core
gpgcheck=0
enabled=1

[root@xcat01 ~]# vi /etc/yum.repos.d/xcat2dep.repo
[xcat-dep]
name=xCAT 2 depedencies
baseurl=http://リポジトリサーバのIPアドレス/yum/x86_64/xCAT/xcat-dep/rh7/x86_64
gpgcheck=0
enabled=1

リポジトリを初期化
[root@xcat01 ~]# yum clean all

ここまでくれば、あとはインストールするだけ。yum installコマンドを実行してxCATをインストールしちゃいましょう。

[root@xcat01 ~]# yum install xCAT

4. xCAT管理ノード初期動作確認

xCATのインストールが完了したら、以下の要領で初期動作確認を行います。

1.パスを追加
[root@xcat01 ~]# source /etc/profile.d/xcat.sh

2.バージョン確認
[root@xcat01 ~]# lsxcatd -a

3.xCAT用DB初期化
[root@xcat01 ~]# tabdump site

4.起動、停止の動作確認
[root@xcat01 ~]# systemctl start xcatd
[root@xcat01 ~]# systemctl stop xcatd

※起動停止ステータス状況の確認は、以下で確認します。
[root@xcat01 ~]# systemctl status xcatd

ついでに、特に問題ない場合はxcatdがOS起動時に自動起動するように設定しておきましょう。
(xcatはchkconfigから変更する)
[root@xcat01 ~]# chkconfig xcatd on
[root@xcat01 ~]# chkconfig xcatd --list

いかがでしたでしょうか。今回はxCAT管理ノードのインストール手順について紹介しました。
一見、取っ付きにくそうなxCATですが、インストール手順はいたってシンプルなものです。
ぜひ、これを機会に試してみてはいかがでしょうか。

鈴木
2008年にIBMに入社。
長くエンタープライズのお客様を複数担当。最近はHPC分野を経て金融のお客様を担当。
Unix/Linux系がメインスキル。
最近は、InfinibandやOSS(Zabbix, xCATなど)など社内スキル保有者が少ないレアキャラを目指して活動中。

夜は焼鳥の匂いに誘われて焼酎1杯だけ立ち飲みして帰る純情派のインフラSE。
焼鳥の味付けは塩。

 

(鈴木)サーバ系のインフラSEでxCATは知っていて損はないOSS

鈴木です。

私自身、IBMに入社して以来、主にサーバ系のインフラSEとして活動を続けてきました。

インフラSEというと、サーバの電源ON/OFFや、OS導入といった、いわゆる単純作業がつきもの。その割には、サーバの台数が多くなってくるとコストがかさむ箇所も、この作業だったりしますよね。

今でこそ、一子相伝の自動化スクリプトや、Chefなどが出てきましたが、これらはどちらかというとOSより。

HW自体の操作などは、やはり人手が必要になりがちです。

このような状況の中、HWレイヤーからOSレイヤーまで自動化したい方にご紹介したいOSSがあります。

1.xCATとは

「xCAT」は、Extreme Cloud Administration Toolkitの略で、いわゆる「大規模クラスター」向けに開発された管理ツールです。

ここで言う「大規模クラスター」とは、例えば以下のようなもの。

  • HPC(High Performance Computing)
  • オンラインゲーム
  • クラウド etc...

いわゆる同じ機能や設定を持った大量のサーバ群のプロビジョニング(OS、MWなどの自動導入、設定)や、HW操作を一括管理することを、xCATは得意としています。

なお、公式HPを見る限り、2011年あたりから実用化されているように見えますね。(私自身、xCATが実稼動環境で使われているのを見たのは、この頃からです)

2.xCATができること

公式HPから抜粋しちゃいますが、xCATの主な機能は以下のとおり。(参考:https://xcat.org/

  1. Provision Operating Systems on physical or virtual machines: RHEL, CentOS, Fedora, SLES, Ubuntu, AIX, Windows, VMWare, KVM, PowerVM, PowerKVM, zVM.
  2. Provision using scripted install, stateless, statelite, iSCSI, or cloning
  3. Remotely manage systems: lights-out management, remote console, and distributed shell support
  4. Quickly configure and control management node services: DNS, HTTP, DHCP, TFTP, NFS

上記を見ると分かるとおり、xCATは主要なインフラコンポーネントの大半をカバーしていることが分かります。これだけの機能を全て使いこなせたら素晴らしいだろうな・・・と常々思っている次第(笑)

別記事で紹介する予定ですが、私はxCATで約400台の物理サーバに対してOSプロビジョニングとHW管理する環境を実装しました。

ただ、クローニングや仮想化環境のプロビジョニングまでには至っていないので、今後試す機会があれば、それも随時紹介していきたいと思っています。

3.xCATの知識を身に着ける前に覚えておきたい推奨知識

xCATは、HW管理とプロビジョニング機能を併せ持ったOSSであることを紹介しました。

HW管理の箇所についてはコマンドと機能を覚える程度なので、そこまで深い知識は必要ありません。

一方で、プロビジョニング機能に関する知識を身に着けていこうとすると、事前に知っておいた方が理解が早まる知識があります。 それが、「キックスタートファイル(ksファイル)を使ったOSのネットワークインストール(NWインストール)」。

例えばRHEL系のOSインストールなどの場合は、事前にどのような設定でインストールするのかを記述した「ksファイル」を作成しておくことで、いちいちインストール画面での入力を必要とせず、OSを自動インストール、自動設定することができます。

また、NWインストールすることで、CD/DVDでインストールする時より遥かに早い時間でOSインストールを完了できます。

これを合わせ技として実装したものが、、「キックスタートファイル(ksファイル)を使ったOSのネットワークインストール(NWインストール)」です。

実は、xCATもプロビジョニングの際は、同じような原理で動作します。(若干、設定箇所が違うくらい) 。

なので、もし時間がある方は、「キックスタートファイル(ksファイル)を使ったOSのネットワークインストール(NWインストール)」についても知識を得ておくと良いかもしれませんね。 (もしかすると、私の方でこの記事も書く・・・かも)

4.おわりに

今回はxCATについて以下を紹介しました。

  • xCATができること
  • xCATの前提知識

なお、xCATについてWeb検索しても、公式HP以外あまり詳しい情報は出てこないですね。マイナーOSSってことですかね(笑)

とはいっても、自動化を推進したいと思っている方にとっては、覚えておいて損はないスキル。このブログを通しても、基本的な設定方法や使い方を紹介していきたいと思います。

 

この記事の執筆者 :鈴木

2008年にIBMに入社。 長くエンタープライズのお客様を複数担当。最近はHPC分野を経て金融のお客様を担当。 Unix/Linux系がメインスキル。 最近は、InfinibandやOSS(Zabbix, xCATなど)など社内スキル保有者が少ないレアキャラを目指して活動中。 夜は焼鳥の匂いに誘われて焼酎1杯だけ立ち飲みして帰る純情派のインフラSE。 焼鳥の味付けは塩。

(中上)あまり知られていない気がする、vSphere ESXiのディスクI/O改善方法

こんにちは、IBMの中上です。

入社5年目で、入社以来、現場SEとして、主にVMwareLinuxWindowsを中心にシステム設計・構築・運用などを担当しています。

特に、VMwareLinuxを触る機会が多い気がします。
(※単に、Windowsに関しては比較的お客様でも触れるからというのが背景です)

今回は、VMware社が提供する中心製品であるvSphere ESXiのちょっとしたTipsを紹介しようと思います。

1.「ディスクI/Oが重い気がする」

入社以来、特に運用フェーズの支援をしていると、よくこんなお問い合わせの電話を受けます。

分かります、もっさりとしていると、それだけですごくストレスですもんね。

こういうパフォーマンス問題は厄介なもので、エラーらしいエラーは出ていないけれども「普段に比べてなんとなく処理が遅い気がする」という事象の表れ方をします。

そのため、発生している事象に対する切り込み方が非常に難しい。

大抵、電話をかけてくださる情報システム部の方も「困っているんです…」と困り顔が目に浮かぶような声音であることが多い気がします。

 

一般には、こういうパフォーマンス問題の時には、仮想OS、物理ホスト、ストレージそれぞれの観点で、普段とは異なるリソース使用状況が生まれていないか、一つ一つ潰していくことになります。

この切り分け方法を網羅的に書くことはそれ自体がかなり難しいですし、環境や設計にも依存しますので、ここでは割愛します。

 

さて、ディスクI/Oに関しては、問題が余計に面倒な様相を呈してきます。

その背景としては、主に2点あると思っています。

  1. 目に見えにくいため、発見が遅れがち
  2. 発見されても、速攻で対処できるとは限らない

1. に関しては、経験則として、ディスクI/Oを常時監視しているような環境をあまり知りません。レスポンスタイムの監視というのがなかなか難しいというのがあると思います。

2. に関しては、ボトルネックが見つかったとしても、チューニングが難しかったり、原因次第ではより高速なストレージに変更するより他ないなどのケースがあり得えます。

極端な話、仮想OSのCPUやメモリがリソース不足を起こしているのであれば、足してあげれば良いのですが、ディスクに関してはそういうわけにもいかないことがあるのですよね。

予防策としては、性能要件を十分に定めて要件を十分に満たすストレージを使用する、共有ストレージを共有しすぎない、といった根本的な計画の部分に関わることになると思います。

 

2. ESXiのディスクI/O改善Tips

ESXiから外部ストレージに対するI/Oに話を絞ります。

外部ストレージ側が対応していれば、ESXiの外部ストレージへのパス選択方法として「ラウンドロビン」を選ぶことができます。
(※少なくとも弊社のミッドレンジ以上の製品は大半が対応している印象です)

ラウンドロビンがもたらす効果として、全てのアクティブなストレージパス間での負荷を分散できます。

他のパス選択ポリシーとして「最近の使用」「固定」などがありますが、これらとは異なり、論理的には全てのアクティブパスの帯域を使用できることになります。

 

ただ、VMwareラウンドロビンポリシーに関しては、以下の特徴があります。

1 つのパスは、特定の量のデータが送信されるまで選択されたままで使用されます。その量に達すると、PSP ではリスト内の次のパスが選択されます。

で、このパスが切り替わる基準が、デフォルトでは、ディスクI/O 1000回になっています。

これがなかなかの問題で、例えば、特定のパスが8Gbps=1GBだとした場合に、I/O 1000回以内に1GBが送受信されると、一部のI/Oが待機させられることになるのです。

これでは、複数ストレージパスを持たせ、負荷分散を図ったにも関わらず、逆にI/O遅延を引き起こす可能性があります。

 

この切替基準は、ESXiの再起動等を伴わず変更が可能です。

例えば、Queue Depthのようなパラメータは、ESXiの再起動が必要になりますので、仮想マシンの退避などの調整がどうしても発生してしまいます。

それに比べれば、かなり融通がききやすいチューニングポイントとなります。

 

個人的には、このデフォルト値については、ちょっとその意図が分からないなあというのが正直なところです。

実際に、以前私が担当していた案件にて、ディスクI/Oが非常に激しい仮想サーバのパフォーマンスチューニングの中でこの設定変更を入れることで、ディスクI/O処理を改善させることができました。

 

詳細は、以下のKBを参照して下さい。

kb.vmware.com

 

3. 前提・留意点

まず、そもそもとして、ラウンドロビンが構成可能なストレージであることを確認する必要があります。

確認の際には、VMwareを触っている人であればお馴染みだと思いますが、VMware Compatibility Guideのサイトでご確認下さい。

VMware Compatibility Guide - System Search

 

また、KBの中にも記載がある通り、ストレージベンダー側がこの構成を推奨するかは確認が必要になります。

 

既に本番運用中の環境の場合、それまでは待機させられていたI/Oがストレージに集中する可能性があるため、変更した直後から、ストレージ側への負荷が高くなり、逆にレスポンスタイムを悪化させてしまう可能性もあるでしょう。

必ずしも1000→1に変更する必要はなく、少しずつ数値を下げていくような形でリスクヘッジすることも検討したほうが良いと思います。

 

変更の際には必ずesxtopを確認しましょう。

ディスクデバイス画面またはディスクアダプター画面で、IO数、帯域使用量、レスポンスタイムをリアルタイムに観察した方が良いでしょう。

なお、上で少し言及した案件の際には「KAVG/cmd」の値がチューニングによって改善されました。

 

4. おまけ(esxtopについて)

esxtopは、ESXiのパフォーマンス状況をリアルタイムに確認できるツールです。

ディスクI/O、特にレスポンスタイムに関しては、以下のような区別がなされています。

  • GAVG … ゲストOSから見たレスポンスタイム
  • KAVG … VMKernelで消費される時間
  • DAVG … ストレージデバイスで消費される時間

つまり、GAVG = KAVG + DAVGという式になります。

今回のチューニングで効果が出るのは、恐らくKAVGだと思います。ストレージパスの帯域が飽和することで、VMKernelの中でI/Oが待機されることになるので、その消費時間はKAVGの値に加算されるものだと思われます。

逆に、DAVG側が高い値を取っている場合は、今回のチューニングはあまり効果を与えないことだと思います。

この場合は、残念ながらストレージ側が性能限界ということになります。

 

5. 最後に

社内で設計検討する際に「パス選択ポリシーはラウンドロビンで」という点までは話題に上ることは多いのですが、流石に上のチューニングポイントについてはあまり話に聞いたことがありませんでした。

ラウンドロビン=I/O 1回毎に次のパスを使用する」というようなイメージを持ちかねませんので、ちょっと気をつけたいところですね。

 

それでは、引き続き、次の投稿をお楽しみに!

 

この記事の執筆者:中上

2013年にIBMに入社。エンタープライズ系のお客様を主に担当するインフラSE。メインスキルは、VMwareLinuxWindowsなど。入社時の技術研修で勉強したSystem xシリーズは、プロジェクトに配属される頃にLenovo社に売却される。以来、自社製品に殆ど触れることなく気づけば5年目。

初対面の人には「神経質そう」「理系っぽい」と言われがちだが、根っからの文系人間。
趣味は音楽。入社以来、年1本のペースでギターが増殖中。

(鈴木)IBMで働く現場SEメンバーがはてぶ(ブログ)始めたよ

IBMの鈴木です。IBMの現場SE部門でインフラSEを10年ほどやっています。

このたび、うちの部門の試みとして、「IBMの現場SEが培ってきた様々な情報」をこのブログに書いていくことにしました!

 

1. IBMの現場SEがこんなことを書いていく

どんなことを書いていこうか・・・私は同じ部門のメンバーと話し合いました。

その結果・・・

あれこれ出すぎてまとまりませんでした(笑)

例えば以下のような内容です。

  • テクニカルな知識の公開
  • 何かに対するレビュー
  • 成功談・失敗談
  • いちSEとして、いちIBMerとして、いち人間として言っておきたいこと
  • お勧めのお店紹介


などなど・・・種々様々、雑多に書いていく予定です!おそらく、書く人間によって書くカテゴリも書きっぷりも全然違ってくると思います。

はっきり言って私も誰がどんな記事を書くのか想像もつきません(笑)しかし、「誰かの役に立てれば」という思いは、私たちの唯一の共通認識です。

2. IBM 現場SEがブログを始めた理由

なんでまたIBMのSEが、しかも複数人でこのようなブログ活動をするのか?

 それには、私たちの部門にこんな課題があるからです。(部門といっても、10数人くらいの最小単位の集まりですが)

 

  • 現場SEの知識をアウトプットする機会がない(本当はあるんだけど、積極的にアウトプットしないことが少なかれある)
  • 誰がどんなスキルや考え方をもっているのか、同じ部門内ですら周知できていない
  • ブログって何か面白そうじゃん!やってみようぜ!

まぁ、同じ部門と言っても全員で同じ仕事をするわけではないので、実はプロジェクトメンバーより絡みが少なかったりするわけです。(「SEあるある」ですねw)

 そこで、ブログという情報媒体を活用することで、楽しみながらこの課題を乗り越えていこうと思っています。

3. このブログの目指すところ

このブログを書くメンバーは私も含め、SEです。なので、同じような仕事をしているSEの方に、少しでも役に立つ情報を提供できたら、こんなに嬉しいことはありません。

 

これが、このブログの目指すところです。

 

もしかすると、記事の内容が読み手に正確に伝わらなかったり、難しいと感じさせてしまうかもしれません。 そういうのをブログを通して少しずつ改善していくことで、我々も成長できると思っています。

 同時に、我々自身が抱えている課題(アウトプット機会が少ないなど)も、このブログに記事を投稿していくことで改善できたらいいなーと緩めに期待しています。

4. 投稿頻度は月に数件を目標

本当は、毎日投稿できるといいのですが、そこまでの体力がありません(笑)

 おそらく、月に数件程度の投稿頻度でゆる~く運営していくことになると思います。

 その分、違う個性の人間が、イロイロな記事を書いていく予定なので、ゆる~く見ていただければ幸いです!

 ということで、「IBM現場SEのITな日々」の開設にあたり、私、鈴木より簡単なブログの紹介をさせていただきました。

今後とも当ブログをよろしくお願いします!

 

この記事の執筆者 :鈴木

2008年にIBMに入社。長くエンタープライズのお客様を複数担当。最近は金融系。純情派のインフラSE。Unix/Linux系がメインスキル。 最近は、InfinibandやOSS(Zabbix, xCATなど)など社内スキル保有者が少ないレアキャラを目指して活動中。

仕事柄(?)、血液型をA型に見られがちだが、弩級のB型です。 趣味はカメラ。IT知識よりカメラの方が詳しいのでは?という説もあり。