サーバー・システムにおける運用管理

仮想化やクラウド・コンピューティングの発達によって、コンピュータ・システムはますます複雑になっています。仮想化技術やクラウド・コンピューティングを導入すると、エンドユーザーの立場では、非常に使い勝手がよく、電力消費や物理サーバーの台数が抑えられるというメリットがあります。この一方、運用管理を行う立場では、個々の物理サーバーやゲストOSがどのような状態なのかを正確に把握しておく必要が生じます。

システムの管理者は、サーバーの状態やアプリケーションの稼働状況を把握するために、さまざまなツールを駆使します。実績が豊富な有償のツールもあれば、無償で提供されている優秀なツール、そうでないツールも存在します。このため、自社のシステムに合った実績のある手法を見極める必要があります。

本連載では、物理サーバー・レベルでの管理の基本を紹介しつつ、特に近年クラウド・コンピューティングに採用が検討されている、Red Hat Enterprise Linux 6とFreeBSDに適用可能なOSS（オープンソース・ソフトウエア）を使った運用監視と、ベンダーが提供する無料の監視ソフトウエアによる運用管理の手法を紹介します。

サーバー管理手法

ITシステムの管理者は、物理的なサーバーやストレージの状態を把握するために、サーバー・ルームに足を運びます。サーバーの物理的な状態を確認するためには、ハードウエアが搭載しているLEDの色、点滅、点灯状態、警告音の有無、などを確認する必要があります。

サーバーやストレージの異常を、人間の目視によって確認することは、非常に重要なことです。しかし、目視だけでは分からない異常も、数多く潜んでいます。目視だけでは分からない異常は、サーバーにログインして確認します。管理対象がLinuxやFreeBSDなどのサーバーである場合は、端末エミュレータを使ってログイン・プロンプトを出し、コマンドを入力することで管理できます。

一般的に、ハードウエアの状態は、目視で確認する場合が多くみられます。しかし、サーバー・ルームが遠隔地にある場合は、管理者の移動のための交通費削減という観点から、遠隔からの管理が行われます。遠隔からの管理手法を理解しておけば、管理者は地理的な制約から解放されるため、非常に効率的です。

ハードウエアが遠隔地にある場合は、クライアントから管理対象のサーバーに管理専用ネットワーク経由でログインすることで、管理を行います。管理対象のサーバーにOSがインストールされている場合は、telnet、ssh、VNCなどを利用して遠隔操作を行います。一方、OSがインストールされていない場合でも、遠隔地からサーバーの電源ON/OFFやBIOS設定、RAIDコントローラの設定、POST画面のコンソール表示とキーボード操作を行えるようにしておくことが重要です。

一般には、仮想電源ボタンや仮想コンソールなどの豊富なサーバー管理インタフェースが用意されています。これにより、管理者の管理工数を大幅に低減できます。これらは、規模の大小に関係なく、サーバーの運用管理には必須ともいえるコンポーネントとなっています。

例えば、HP ProLiantサーバーに搭載されている管理チップであるiLO3による仮想電源ボタン、仮想コンソール、仮想メディアを駆使することで、OSのインストールの前段階のハードウエア管理で威力を発揮します。最新のiLO3仮想コンソールでは、複数の管理コンソールを複数開き、ウインドウを拡大・縮小できる機能が備わっています。これにより、複数のLinux、FreeBSD、Windowsなどを1台のクライアントPCの1画面上で、コクピットのように管理できます。

以下の図では、遠隔地にある、OSが入っていないサーバーと、それぞれRed Hat Enterprise Linux 6とWindows Server 2008 R2がインストールされている、合計3台のサーバーの画面を、1つのクライアントPCの画面上で縮小表示させ、操作を行っている様子です。

図1: 最新のx86サーバー向け仮想コンソールでは、遠隔地にある複数のサーバー画面を縮小表示し、コクピットのように操作が可能。クライアントPC側はWebブラウザで操作ができる（クリックで拡大）

従来であれば、ディスプレイ切り替え機を用いて1台ずつサーバーの画面を出力して切り換えて確認していました。これが、上図のようなサーバー搭載の管理チップの機能を使うことで、サーバーの死活状態やOSの状況などをクライアントPCの1画面に集約して確認できるようになりました。管理効率を大幅に向上させることができます。

Linux、FreeBSDサーバーのハードウエア情報の取得とOS管理

LinuxやFreeBSDなどのオープンソース・ソフトウエアを同梱（どうこん）したサーバーの稼働状況を把握する一般的な方法は、OS付属のシステム管理用コマンドを駆使して情報を収集するというものです。サーバーのコンポーネントであるCPU、メモリー、RAIDコントローラ、RAIDコントローラ配下のディスク、NICの状態を管理します。

最新のRed Hat Enterprise Linux 6やFreeBSD 8.1では、コマンド・ラインとGUIによる、ハードウエア・コンポーネントの管理、監視が行える、便利なツールが用意されています。以下では、世界的に圧倒的なシェアを誇る米Red Hatの最新OS、Red Hat Enterprise Linux 6と、Web系システムで採用が見られるFreeBSDに関する管理手法を紹介します。

CPUの管理手法

LinuxやFreeBSDにおけるCPUの管理は、主に、CPUの認識、CPU利用率、CPUの動作周波数の管理などです。CPUは、システム全体に大きくかかわる重要なコンポーネントであるため、システムの要件に応じた事前設定の基本を知っておく必要があります。まずは、OSの有無に限らず、CPUがハードウエアから正しい個数で認識されているかどうかを確認する必要があります。やり方は、サーバーに搭載されている管理用チップにログインし、システムが認識されているCPUの詳細を確認します。

以下の図は、1CPUあたり6コアのXeon CPU 2.66GHzを搭載したサーバーの様子を示したものです。ハードウエアとして、CPU数、コア数、ハイパースレッドの有無などが分かります。

図2: 認識されているCPU情報を確認する。上記では1CPU、6コアでHyper-Threading Technologyが有効になっており、12スレッドが有効なCPUが搭載されていることが確認できる（クリックで拡大）

では、上図のCPUを搭載したサーバーにOSをインストールすると、CPUの状態がどのように見えるでしょうか。Red Hat Enterprise Linux 6をインストールし、less /proc/cpuinfoで確認してみると、以下のように表示されます。

図3: ハードウエアで認識されるCPU周波数（2667MHz）と現在の動作周波数（1596MHz）が異なっている点に注意する（クリックで拡大）

/proc/cpuinfoにより、Red Hat Enterprise Linux 6では、現在のCPU動作周波数が1596MHzになっていることが分かります。これは、OSが持つ、CPU周波数を動的に変更する仕組みによって、周波数が抑えられて動作しているためです。この設定は、/etc/sysconfig/cpuspeedファイルのGOVERNORパラメータで設定することが可能です。

図4: Red Hat Enterprise Linux 6における/etc/sysconfig/cpuspeedファイルでのGOVERNORパラメータの設定例。パラメータとしてpowersave、performance、ondemandが設定可能である

GOVERNORの値をpowersaveにすると省電力モードになり、performanceにすると最大周波数で動作します。ondemandにするとCPU周波数は必要に応じて変化するようになります。GOVERNORの値を変更したら、serviceコマンドでcpuspeedサービスを再起動させます。

# service cpuspeed restart

大量のサーバーを管理しなければならないデータ・センターにおいては、しばしば消費電力が気になる場合があります。省電力で運用したい場合はGOVERNERパラメータにpowersaveを設定します。一方、製造業における解析サーバーや研究施設での科学技術計算システムなどでは、CPUによる計算を最大限利用するため、GOVERNORはperformanceで設定される場合もあります。

認識されているCPUの個数に注意する

サーバーに搭載されているCPUソケット数、コア数、Hyper-Threading Technology設定の有無により、OSから見えるCPUの数も異なるため、注意が必要です。認識されているCPUの数を知るには、Red Hat Enterprise Linux 6の場合は、/proc/cpuinfoでも分かりますが、CPUの数とそのCPUのどのような状態を知りたいのかによって、駆使するコマンドが異なります。CPUの個数と現在の動作周波数を一度に知る場合は、/proc/cpuinfoを使うのが便利です。

# grep "MHz" /proc/cpuinfo

図5: Red Hat Enterprise Linux 6における/proc/cpuinfoの表示例。CPU個数と現在の動作周波数を一度に見ることができる

CPUの個数とCPUそれぞれの動作周波数を見る場合には、さまざまな方法がありますが、topコマンドの利用が便利です。topコマンドは、CPU利用率の高いプロセスやプロセスIDを監視する場合に利用しますが、topコマンドのサブコマンドを利用すると、CPUコアごとのCPU利用率の様子をリアルタイムに見ることが可能です。

Red Hat Enterprise Linux 6で用意されているtopコマンドは、topコマンドが表示されているウインドウ内で、サブコマンドの「1」を入力すると、CPUコアとそのコアごとの利用率をリアルタイムで表示することが可能です。topコマンドは通常「&（アンパサンド）」を付与せずに、フォアグラウンドで実行します。

図6: Red Hat Enterprise Linux 6におけるtopコマンドでのCPU利用率の監視。サブコマンドを実行することで、各CPUの利用率を見ることができる（クリックで拡大）

FreeBSDにおいてCPUの個数を把握するには、dmesgコマンドやtopコマンドを利用します。FreeBSDのtopコマンドでは、STATE値とTIME値の間に「C」値が表示でき、現在どのコアでどのようなプロセスが実行されているかを知ることができます。

dmesgコマンド	topコマンド
図7: FreeBSDにおけるdmesgコマンド、topコマンドでのCPU個数の把握の様子（クリックで拡大）

Red Hat Enterprise Linux 6とFreeBSDでのtopコマンドに、仕様の違いが見られることに注意してください。

CPU利用率の履歴を保存しておく

CPU利用率をリアルタイムで見たい場合には、topコマンドやvmstatコマンドなどが有用ですが、過去のCPU利用率をファイルに保存しておき、あとで閲覧したい場合があります。そのような場合には、sarコマンドが便利です。sarコマンドでCPU利用率を監視するには、-uオプションを付与し、ファイルに保存するには-oオプションを付与します。

# sar -u 1 -o /root/sar.cpu.log

出力したファイル、sar.cpu.logは、バイナリ形式で保存されます。保存したバイナリ形式を使って過去のCPU利用率を見るには、-fオプションを指定します。

# file /root/sar.cpu.log
sar.cpu.log: data
# sar -f /root/sar.cpu.log

図8: Red Hat Enterprise Linux 6におけるsarコマンドによるCPU利用率の監視。ファイルに保存できるため、サーバーの過去のCPU利用率を確認することができる（クリックで拡大）

SMPを制御しているAPIC

最近のサーバー・システムでは、マルチコアのCPUが複数ソケット搭載されており、1Uサーバーにおいて、CPUコア数が8、12、24というSMP（Symmetric Multi Processing）システムも珍しくなくなりました。

SMPと呼ばれる機構は、IntelやAMDプロセッサを搭載したx86サーバー以外のUNIXサーバーにおいて、古くから一般的に存在していました。現在では、x86サーバーにおいてマルチコアCPUが搭載されるようになり、仮想化やクラウド・コンピューティングのニーズも後押ししたことから、x86サーバーでのSMPシステムの利用が一般的になりました。

IntelやAMDプロセッサーを搭載したx86サーバーのSMPシステムは、APIC（Advanced Programmable Interrupt Controller）と呼ばれる割り込みコントローラや、ACPI（Advanced Configuration and Power Interface）と呼ばれる電源制御機構が制御を行っています。このため、APICやACPIのOSに関するパラメータを適切に設定しないと、SMPとして認識できないばかりか、システムの安定稼働にも影響を及ぼします。

例えば、FreeBSDにおいては、OSのAPICおよびACPIのパラメータを、/boot/device.histsファイルに記載することにより、APICやACPIを有効化または無効化することができます。以下は、FreeBSDにおけるOSのAPICとACPIのパラメータを有効化することで、OSからSMPとして認識させる設定例です。

# vi /boot/device.hists
…
hint.apic.0.disabled="0"
hint.acpi.0.disabled="0"
# reboot

/boot/device.hintsに、hint.apic.0.disabled="0"とhint.acpi.0.disabled="0"を記述することで、APICとACPIを有効にしています。このパラメータはOS起動時に読み込まれますので、パラメータを追加や変更した場合はFreeBSDを再起動させます。

図9: FreeBSDにおけるAPICの様子。dmesgコマンドで、APICとACPIの状況を確認できる（クリックで拡大）

APICやACPIをdisableにすると、SMPで認識せず、1CPUとして認識します。このため、システムのパフォーマンスが低下します。しかし、ACPIによる電源制御機能を切ることでシステム障害の切り分けを行う場合もあります。システム管理者は、APICとACPIを無効にする影響を熟知した上で運用を行う必要があります。通常は、APICを有効にしてSMPシステムとして運用しますが、OSが起動できない場合や追加コンポーネントの認識可否のトラブル・シューティングのための緊急の対応の場合は、その限りではありません。

サーバー環境におけるメモリー管理

近年、サーバーのECCメモリー・モジュールの利用は、大容量化が進んでいます。仮想化やクラウド・コンピューティングにおいて、ProLiantサーバーのようなIntelやAMDプロセッサを搭載したx86サーバーが広く利用されるようになった背景には、CPUのマルチコア化以外に、ECCメモリー・モジュールの大容量化が挙げられます。

LinuxやFreeBSD環境に限らず、OSが利用できる最大メモリー容量は、利用しているOSのアーキテクチャが32ビット版なのか64ビット版なのか、また4GB以上の壁を越えられるカーネルを使っているかどうかによって変わります。

近年、アプリケーションの対応状況から64ビット版OSを利用することが多くなり、4GBメモリーの壁を意識することはあまりなくなりました。しかし、レガシー・システムのアプリケーションの開発費用削減や旧システムのP2V移行などにより、やむなく32ビット版OSを利用することもあります。

そのような場合も含め、メモリーの管理では主に、OSのアーキテクチャ、メモリー容量、メモリー利用率の確認が必要になります。OSのアーキテクチャは、unameコマンド、メモリー容量はvmstatや/proc/meminfo、メモリー利用率についてはtopコマンドなどの利用が一般的です。

# uname -a
Linux dl360g7rhel60.jpn.linux.hp.com 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

# cat /proc/meminfo |grep Mem
MemTotal:       18389460 kB
MemFree:        17331228 kB

また、サーバーでは、ECCメモリーが搭載されているかどうかのチェックをしたい場合があります。そのような場合は、ベンダーから無料で提供されているhpasmcliなどの管理コマンドを利用することで、簡単に確認することができます。

図10: unameでアーキテクチャを確認し、/proc/meminfoでメモリー容量、使用量を確認している様子。また、ベンダー提供の管理コマンドによりメモリーがECC対応かどうかもあわせて確認している（クリックで拡大）

CPUの利用率と同様に、メモリー使用量を時系列で見たい場合があります。この場合にも、sarコマンドが有用です。sarコマンドでメモリー使用量を監視するには、-rオプションを付与します。ファイルに保存する場合は、-oオプションが利用できます。CPU利用率と同様にバイナリ・データで結果が保存されます。

# sar -r 1 -o /root/sar.mem.log

過去のメモリ使用量の状態を確認するには、sarコマンドに-fオプションで出力済みのバイナリ・ファイルを指定します。

# sar -f /root/sar.mem.log

図11: Red Hat Enterprise Linux 6に付属のsarコマンドにより、メモリーの空き容量や使用量、利用率の時系列データをファイルに保管しながらリアルタイムで監視を行っている様子（クリックで拡大）

上図の例では、%memusedの値が6.82%になっており、メモリー利用率が低いことを意味しています。

ストレージの管理

サーバーの運用管理において、I/O周りの管理、監視は、多くの管理者にとって悩ましいものです。内蔵ディスクだけでなく、RAID構成の監視、外付けのFibre Channel（FC）ストレージのFC冗長経路監視や、iSCSIストレージの性能監視など、多くの種類の管理手法を学ぶ必要があるからです。

本連載では、オープンソース・ソフトウエアを使った、非常に基本的なI/O管理、監視を行う手法を述べます。さまざまなコマンドやツールを駆使しますが、通常は、ストレージ・システムの種類によって運用管理ツールは大きく異なります。

自社で導入しようとしているストレージ・システムがどのようなもので、どのようなツールが適しているのかを見極める必要があります。ここでは、広く一般的に利用されており、情報も集まりやすく使いやすい、非常に基本的なツールに限って取り上げます。

コマンド・ラインで使うストレージ管理ツール

Linuxにおけるストレージ管理は、一般的には、fdiskやdfコマンドによるパーティション管理が挙げられます。ここで、I/O性能の監視においては、LinuxとFreeBSDでは管理方法が異なります。Linuxにおいては、パーティションのI/O性能監視として、iostatコマンドとsarコマンドを利用します。

sarコマンドでは、LUN（下図では、sda、sdb、sdcなど）ごとに監視するため、-dpオプションを付けるのが一般的です。以下は、Red Hat Enterprise Linux 6におけるsarコマンドを使って、LUNを表示しながら1秒ごとに性能を監視し、合計4回出力する例です。

# sar -dp 1 4

図12: Red Hat Enterprise Linux 6に付属するsarコマンドにより、ディスク性能監視を行っている様子。-dpオプションによりディスク・パーティション名での表示が可能（クリックで拡大）

ディスク性能監視の場合も、-oオプションにより、バイナリ・ファイルに保管することが可能です。バイナリ・ファイルの閲覧は、-fオプションで行います。

無料で入手できるRAID監視ツール

サーバーには、一般的に、サーバー・ベンダーから提供されるRAIDコントローラがオンボードで搭載されていることがほとんどです。RAIDコントローラーに複数ディスク・ドライブ装置を接続し、RAID1やRAID5などのアレイを構成することで、ディスク・ドライブ装置単体の障害がシステム全体のダウンにつながらないようにするためです。

一般的に、RAIDコントローラによるRAID1やRAID5構成はハードウエアRAIDと呼ばれ、サーバーでは一般的に利用される技術です。ハードウエアRAIDによるRAID1やRAID5を構成しておけば、単体のハード・ディスク・ドライブに障害が発生した場合でも、OSがそのまま稼働し続けますので、業務は継続できます。

しかし、障害が発生したということを運用管理者に伝える仕組みが必要になりますので、RAIDコントローラ配下のどのディスク・ドライブに障害が発生したかを知ることが必要です。これには、オープンソースの管理ソフトウエアよりは、ベンダーが無料で提供しているRAID監視ツールを導入するのが近道です。

例えば、HP SmartArrayコントローラ用のRAID監視ツールに、hpacucliコマンドがあります。RAIDコントローラの機種、物理ディスクの容量、現在のRAID構成状態（RAIDレベルや論理ディスク容量など）を簡単に確認することができます。以下は、hpacucliコマンドによって、HP ProLiant DL360G7にインストールされたRed Hat Enterprise Linux 6が稼働した状態で、内蔵のHP SmartArray RAIDコントローラ情報を閲覧した様子です。

図13: Red Hat Enterprise Linux 6が稼働した状態で、RAIDコントローラの監視を行っている様子。2つの物理ディスク（physicaldrive）によって構成されたRAID1による論理ディスク（logicaldrive 1）が正常に稼働していることが分かる（クリックで拡大）

無料で入手できるLED点灯/消灯ツール

高さ1Uのラックマウント・サーバーが大量に導入されるWeb系システムでは、サーバーに障害が発生した場合にサーバーをメンテナンスしなければなりません。例えば、ハード・ディスク・ドライブに障害が発生した場合は、サーバー前面に搭載されているハード・ディスク・ドライブの障害LEDの色を見て、サーバーを特定し、ディスクを交換します。

マザー・ボードやオンボードNICのポート障害の場合は、マザーボード交換を行いますが、交換の際、誤って1段上や1段下の、別のラックマウント・サーバーを引き抜く事故があってはなりません。そのため、障害が発生した場合は、メンテナンスすべきサーバーに目印を付けます。

作業員がサーバーの前面から当該の障害のあるサーバーを確認後、サーバー背面にまわっても別のサーバーと間違えるミスを犯さないように目印の役目を果たすLEDが、サーバーの前面と背面に搭載されています。これは通常、Unit ID（UID）と呼ばれます。サーバー本体に搭載された押しボタン式LEDであり、サーバーの前面からUIDボタンを押すことで、点灯、消灯を行うことが可能であり、サーバー背面のUIDランプも同調するように設計されています。

これにより、作業員は、サーバー前面のUIDボタンでランプを光らせれば、サーバー背面に回っても、UIDランプの点灯と消灯の同調機能によって、誤って別のサーバー・コンポーネントを引き抜くミスを低減できます。

このUIDは、物理的なボタンです。この一方、OS上から点灯と消灯を制御するツールが、ハードウエア・ベンダーから無料で提供されています。HP ProLiantサーバーでは、hpuidコマンドと呼ばれます。-eオプションでUIDランプの点灯、-dオプションで消灯、-sオプションで現在のUIDランプのステータス（点灯、消灯、点滅）を確認します。

# hpuid -e
# hpuid -d
# hpuid -s

図14: hpuidにより、大阪にいるIT管理者から東京の作業員に、メンテナンスすべきサーバーの物理位置を教えることが可能（クリックで拡大）

図15: 無料で入手できるhpuidコマンドにより、サーバー本体に搭載されているUIDランプの点灯、消灯、状態確認を行っている様子（クリックで拡大）

無料で入手できるLED点灯/消灯ツールを使ってアプリケーションを監視

先述のhpuidは、サーバー・メンテナンスの際のミスの低減が本来の目的ですが、これをアプリケーションの監視や作業手順の開始・終了の通知に利用することも可能です。

例えば、Apacheを稼働させているシステムにおいて、Apacheのプロセス監視を行うスクリプトにhpuidを組み込むことにより、Apacheのプロセスの死活監視をUIDによって確認することが可能となります。アプリケーション管理者は、サーバー・ルームに入っただけで、目視によってアプリケーションの状態を確認できるようになります。

下図は、Apacheのプロセス監視を行っている様子です。Apache監視スクリプトhttpcheck_uid.shは、Apacheのプロセスが実行されている場合はUIDが点灯し、Apacheプロセスが実行されていない場合はUIDが消灯するように構成されています。

UIDの点灯と消灯のテストは、httpcheck_uid.shスクリプトを無限ループやcronで実行させておいた状態でApacheのプロセスの実行と停止を行い、UIDが連動して点灯、消灯するかどうかを、目視で確認します。また、hpuid -sコマンドで確認しても構いません。

実は、HP ProLiantサーバーに搭載されているUIDは、遠隔管理用のチップ経由で仮想コンソールにログインした場合、UIDが点滅するようになっています。これには、遠隔管理用チップを経由して遠隔からIT管理者が作業していることを、データ・センター内で、サーバー交換やメンテナンスを行う現場の作業員に知らせる役目があります。不用意なサーバーの抜き差しを防ぎ、現場作業員と遠隔にいるIT管理者の意思疎通を図る、重要な役目も担っています。

図16: Apacheのプロセス稼働状況をUIDの点灯、消灯によって目視で確認できるスクリプトと、その実行のテストの様子（クリックで拡大）

以上、コマンドラインによる、ハードウエアの基本的な監視方法を述べました。

最近のパブリック・クラウド・システムや、ホスティング・サーバー、オンライン・ゲーム・サーバー、科学技術計算サーバーでは、大量のLinuxやFreeBSDが稼働する1Uサーバーにコマンド・ラインの監視ツールを導入し、集中監視を行うという運用が見られます。多くは、CPU、メモリー、ディスクI/O性能、RAIDコントローラの障害監視を行っています。

監視ツールの導入に手間をかけるよりも、OSに付属しているツールやベンダー提供の無料ツールをインストールすることで、比較的簡単に監視を行うことができます。みなさんも、ぜひコマンド・ラインによるシステム監視を行い、日々の業務の効率化に役立ててみてください。