[実践編] Ubuntu Serverの運用・管理、商用製品の利用メリットと今後の展望（前編）

大量の管理対象ノードの管理

スケールアウト型システムでは、管理対象サーバーの台数が増えるため、OSやアプリケーションの設定を一斉に行いたいニーズがあります。クラスターのノード全体が1つの用途に特化している場合やソフトウェアのバージョンが固定化されている場合は、全ノードに一斉にオペレーションを行う運用がみられます。

一方、OSやアプリケーションのアップデート作業が個別に発生する場合や、Hadoopクラスター、OSS系のデータベース・システムのように、マスター・スレーブ方式のシステムの場合は、クラスター全体で一斉に設定を施すことが難しい場合もあります。また、科学技術計算用途のスーパーコンピューターや分析基盤として近年導入が進んでいるHadoopクラスターでは、全体のクラスターを、ユーザーの用途やアプリケーションに応じたサブ・クラスターに分割して運用する場合もあります。
マスター・スレーブ間や複数のサブ・クラスター間の設定ファイル、オペレーションの出力結果の違いを差分表示させることで、システムの構築、運用の効率化を図る運用もみられます。

以下では、スケールアウト型基盤特有の管理手法について、いくつかご紹介します。

スケールアウト型基盤におけるコマンドラインでの作業効率を高めるためには、コマンド発行用のスクリプトをいくつか用意しておくことが一般的です。また、管理の半自動化を実現する便利なツール類がUbuntu Serverの環境で利用可能です。

スケールアウト基盤における公開鍵認証キーのコピー作業

スケールアウト型システムの管理ノードへのファイルコピーやコマンド発行を行うために、公開鍵の登録を行うのが一般的です。事前準備として、/etc/hostsに管理対象サーバーのIPアドレスとホスト名の対応を記述しておきます。

# vi /etc/hosts
172.16.12.1     node001.jpn.linux.hp.com		node001
172.16.12.2     node002.jpn.linux.hp.com		node002
...
172.16.12.254   node254.jpn.linux.hp.com		node254

公開鍵の登録作業は、id_rsa.pubファイルを接続先のホストにscpコマンドによってコピーし、接続先にログイン後、ユーザーのホームディレクトリ配下の.sshディレクトリの下にauthorized_keysファイルとして登録することで実現が可能ですが、ssh-copy-idコマンドを利用することによって、登録作業を簡素化することができます。

大量の管理対象サーバーへの公開鍵の配布を簡素化するコマンド例を以下に示します。

# ssh-keygen -t rsa -b 2048
# for i in `seq -f %03g 1 254`; do ssh-copy-id root@node$i; done

[注意] ssh-copy-idコマンドによる公開鍵登録の初回は、SSH接続先のユーザーのパスワード認証による人間の入力作業が必要になりますので注意してください。

サーバー台数が数百台規模になるようなスケールアウト型システムの場合、ホスト名に数値を与え、先述の/etc/hostsファイルに記述したホスト名のように、ホスト名の一部にゼロ埋めを施したホスト名で管理する場合が少なくありません。ゼロ埋めを施した数値を自動的に生成するには、seqコマンドに-fオプションを付与し、その後に、C言語のprintf関数の数値を表す書式を付与します。

コマンド一斉発行ツール「Taktuk」をスケールアウト型基盤に導入する

Taktukは、複数の管理対象サーバーにコマンドをブロードキャストで発行できる管理ツールです。Ubuntu用のパッケージが用意されており、apt-getコマンドで簡単にインストールすることができます。Taktukを使うには、管理対象となる全てのノードにTaktukをインストールする必要があります。前述のssh-copy-idコマンドによる公開鍵の登録を行えば、公開鍵認証により、パスワード認証による人間のパスワード入力作業を行うことなく、全ノードに対してTaktukパッケージのインストール作業を自動化することができます。
Taktukパッケージのインストールは、apt-getコマンドで行いますが、全管理対象サーバーに対してsshコマンドを使って行いますので、for文を組み合わせてインストールを行います。下記は、管理対象サーバーnode001からnode253までの合計253台のマシンにTaktukをインストールする例です。

# for i in `seq -f %03g 1 253`; do ssh root@node$i "apt-get update -y; apt-get install taktuk -y" ; done

Taktukは、管理対象サーバーをリストアップしたファイルを読み込ませることによって、複数の管理対象サーバーに対してコマンドをブロードキャストで発行することができます。管理対象サーバーをリストアップしたファイルを作成します。

# vi ~/.hostlist
node001
node002
...
node253

Taktukの運用例としては、複数の管理対象サーバーのハードウェア資源の利用状況の確認や、パッケージの一斉インストールなど様々ですが、今回は、Taktukを使って全管理対象サーバーの時刻を合わせてみましょう。

# taktuk -f ~/.hostlist -l root broadcast exec [ " date 040906532014; hwclock --systohc" ]

上記は、dateコマンドで、全管理対象サーバーの時計を2014年4月9日の午前6時53分に合わせる例です。HadoopクラスターやGlusterFS、Cephクラスター等のノード群が協調して稼働するようなスケールアウト型システムでは、初回導入時だけでなく、日常的な利用においても、NTPを使ってノード群の時計を合わせておくことが正常稼働に重要です。

しかし、構築スケジュールや技術要員確保の関係上、NTPサーバーに接続できない状況でクラスターを構築しなければならない場合もあります。このような場合、時計のズレによるソフトウェアの誤動作を回避するためにも、OSおよびハードウェアの時刻を手動で調整する場合があります。

Taktukでファイルの転送を行う

Taktukは、管理対象サーバーへのファイルのコピー（put）や、管理対象サーバーからのファイルのコピー（get）も可能です。スケールアウト型基盤では、単一クラスター内で/etc/hostsファイルを全て同じ記述にするために、管理サーバーで/etc/hostsファイルを作成しておき、全ノードに配布するような運用が多くみられます。このような場合、Taktukを使って一斉に/etc/hostsファイルを管理対象サーバーに転送することが可能です。

以下は、管理サーバーの/etc/hostsファイルを管理対象サーバーの/etc/に一斉にコピーする例です。

# taktuk -l root -f ~/.hostlist broadcast put [ /etc/hosts ] [ /etc/ ]

Taktukを使って、複数の地域に散在するクラスターを管理する

Taktukは、クラスター自体が複数のグループや異なるLANセグメントに散在している場合の一元管理に威力を発揮します。Taktukは、複数のクラスターやグループ、ゲートウェイサーバーで接続された異なるLANセグメントに所属するクラスターに対してブロードキャストコマンドを発行することができます。クラスターがゲートウェイサーバーを経由して、異なるLANセグメントに所属する場合、ゲートウェイサーバーにログインし、個別にクラスターを管理する方法がありますが、部門ごとにLANセグメントが異なる場合に、ゲートウェイサーバーの数だけ、個別ログインが必要となり、管理が煩雑になります。Taktukを使えば、異なるLANセグメントに所属する部門レベルのクラスターが増設された場合のアプリケーションの配備等を一元的に行うことができます。

以下では、上図のように、LANセグメントの異なる3か所のデータセンター（東京、名古屋、大阪）にそれぞれ構築されたスケールアウト基盤を管理サーバー側で一元的に管理する例です。

# taktuk  -l root \
>-G 172.16.1.254 -[ -f ~/.tokyo -] \
>-G 172.16.2.254 -[ -f ~/.nagoya -] \
>-G 172.16.3.254 -[ -f ~/.osaka -] \
>broadcast exec [ “df; free” ]

taktukコマンドに、-Gオプションで、ゲートウェイサーバーを指定します。その後にゲートウェイサーバーが持つ管理対象サーバー群を記述したリストを「-[ -f ファイル名 -]」で指定します。上記では、複数行にわたって記述していますが、1行で入力しても構いません。前提条件として、管理サーバーとゲートウェイサーバー間、ゲートウェイサーバーと管理対象サーバー間で公開鍵認証を使ったssh通信が可能であり、かつ、全てのサーバーにtaktukがインストールされている必要があります。

図1：LANセグメントのスケールアウト基盤をTaktukによって一元管理するシステム例（クリックで拡大）

コマンド一斉発行および差分表示による運用管理の簡素化

コマンド一斉発行の機能を持った商用ソフトウェアとしては、HP Insight CMUが存在します。14年の歴史を誇り、科学技術計算クラスターでは枯れたソフトウェアとして定着しており、その管理性の高さから、米国HPが提供するHadoopのリファレンス・アーキテクチャに選定されている管理ソフトウェアです。
HP Insight CMUは、管理対象のUbuntu ServerにSSHによるコマンド一斉発行を行うためのxterm端末を一斉に起動させることが可能です。また、管理対象ノードで有するファイルやディレクトリ、ファイルの中身の相違を素早く発見するための差分表示機能があります。マスターノードとスレーブノードで設定が異なるようなHadoopクラスターや科学技術計算クラスターにおいて威力を発揮します。何千台の計算サーバーを管理しなければならない場合には、是非導入を検討してみてください。

図2：HP Insight CMUで複数のUbuntu ServerにSSH通信を行い、一斉にコマンドを発行している様子。複数のUbuntu Serverで稼働するサービスの一斉起動・停止等に利用される（クリックで拡大）

図3：HP Insight CMUで複数のUbuntu Serverの状態を差分表示した様子。lsコマンドの結果から、ファイルmap.pyとred.pyがホストh02からh08までのホストに存在しないことがわかる。「cat /etc/lsb-release」の実行結果からホストh01のみがUbuntu 12.04.3　LTSであり、その他のホストは、Ubuntu 12.04.4 LTSであることがわかる（クリックで拡大）

Ubuntu Serverにおけるバックアップとリストア

Ubuntu Serverのシステムバックアップには、様々な方法がありますが、バックアップ対象によってツールを使い分けるのが一般的です。スケールアウト型基盤やFCストレージを使ったデータベース・システム、HAクラスターなどのシステム・アーキテクチャの違い、バックアップ要件によってもツールを使い分ける必要があります。災害対策（ディザスタ・リカバリ）、定期的なユーザー・データのコピー、レプリケーション等の目的に応じてツールを組み合わせて導入するのが一般的です。

図4：スケールアウト型基盤におけるバックアップとリストア（クリックで拡大）

バックアップの基本的な考え方としては、OS領域のバックアップとデータ領域のバックアップがあります。OS領域の復旧は、ハードディスクのマスターブートレコードを含めたイメージバックアップを利用するのが一般的です。イメージバックアップ・ツールとしては、Relax-and-Recover、Bacula、Clonezilla、Mondo Rescueなど様々なオープンソースソフトウェアが存在します。
OS領域以外のユーザー・データ用のバックアップは、tarコマンドによるアーカイブや、rsyncによる遠隔地への同期などがありますが、最近では、rsync以外に、Amazon S3、FTPサーバー、WebDAVサーバーへの同期が可能なduplicityの利用がみられます。本連載では、OS領域のバックアップ・リストアツールとして、設定が非常に簡単なRelax-and-Recover（通称ReaR）を紹介します。

Relax-and-RecoverによるUbuntu Serverのバックアップ・リストア

Relax-and-Recover（通称ReaR）は、システムディスクのOS領域の復旧を行うOSSです。ベルギーのHewlett-Packardの技術者が開発に携わっています。欧州で開催されているOSSのバックアップソフトウェアを主体としたカンファレンスや、様々なLinuxのイベントで紹介されており、設定が簡素なソフトウェアとして知られています。また、UEFI（Unified Extensible Firmware Interface）を搭載したサーバーにも対応しており、現在も開発が進められています。

ReaRは、ブータブルisoイメージやUSBメモリ・イメージを作成することができます。復旧時は、ブータブルisoイメージを使って、リストア対象のサーバーを起動し、ReaRによってNFSサーバーに保管されたバックアップデータを使って、OS領域をリストアします。最近のスケールアウト型サーバーでは、DVDドライブが付いていないモデルも存在するため、CDブートを行う場合は、外付けのDVDドライブを別途用意するか、サーバーの遠隔管理チップの仮想DVDドライブ機能を使う必要があります。最新のReaRは、USBイメージやPXEブートを利用することも可能であり、DVDドライブや遠隔管理チップが利用できない環境にも対応しています。

ブータブルisoイメージの生成とNFSサーバーを組み合わせたバックアップ

ReaRによるUbuntu Serverのバックアップ手法として、NFSサーバーを組み合わせたバックアップ・リストアについてご紹介します。Ubuntu Serverにおいて、バックアップを保管するNFSサーバーの設定を行います。Ubuntu Serverでは、nfs-kernel-serverパッケージをインストールします。

root@nfssvr:~# apt-get update
root@nfssvr:~# apt-get install nfs-kernel-server
root@nfssvr:~# vi /etc/exports
/work001	*(rw,async,no_root_squash)

root@nfssvr:~# service nfs-kernel-server restart
root@nfssvr:~# showmount -e localhost
Export list for localhost:
/work001 *

ReaRをバックアップ対象ノードにインストールします。Ubuntu Serverに対応したReaRは以下のURLから入手できます。

Ubuntu Serverに対応したReaRの入手先：
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/xUbuntu_12.04/all/

# apt-get install mingetty ethtool portmap nfs-client
# apt-get install syslinux-common syslinux genisoimage binutils
# dpkg -i rear_1.15_all.deb

ReaRの設定ファイルは非常に簡素です。バックアップ対象ノードの/etc/rear/local.confファイルを編集し、ブータブルisoイメージとバックアップ・アーカイブを保管するためのNFSサーバーを指定します。今回、NFSサーバーのIPアドレスは、172.16.1.5とします。

# vi /etc/rear/local.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://172.16.1.5/work001/

設定ファイルを記述したら、バックアップ対象ノードからNFSマウントできるかを事前にテストしておきます。

# mount -t nfs 172.16.1.5:/work001 /mnt
# df |grep nfs
172.16.1. 5:/work001 nfs       153G   41G  106G  28% /mnt
# umount /mnt

バックアップ対象ノードで、rearコマンドを使ってバックアップを行います。復旧用のisoイメージとアーカイブが生成され、NFSサーバー側に保管されます。

# rear mkbackup -v

NFSサーバー側にバックアップ対象ノードのホスト名（今回はnode001とします）のディレクトリが生成され、tarアーカイブとブータブルisoイメージが格納されているかを確認してください。

# ls -l /work001/node001/
合計 746244
-rw-r--r-- 1 root root       202  2月 11 01:40 README
-rw-r--r-- 1 root root       265  2月 11 01:40 VERSION
-rw-r--r-- 1 root root   4121569  2月 11 01:43 backup.log
-rw-r--r-- 1 root root 682205952  2月 11 01:42 backup.tar.gz
-rw-r--r-- 1 root root  77604864  2月 11 01:40 rear-node001.iso
-rw-r--r-- 1 root root    197355  2月 11 01:40 rear.log

ブータブルisoイメージとNFSサーバーを組み合わせたリストア

作成したisoイメージを使って、リストア対象ノードをCDブートさせてリストアを行います。DVDドライブが装着されていないProLiantサーバーの場合は、オンボードに搭載されたiLO4チップの仮想DVDドライブ機能を利用することで、物理DVDドライブがなくてもCDブートが可能です。CDブートを行うと、下図のようなReaRのブートメニュー画面が表示されます。

図5：ReaRのリストア時のブートメニュー（クリックで拡大）

「Automatic Recover」を選択するとリストアが実行されます。リストアが成功すると画面に「Success!」と表示されます。対象ノードを再起動させるため、「3」を入力します。

図6：ReaRによるリストアが成功した様子（クリックで拡大）

再起動後のリストア対象ノードにログインし、データが正常にリストアされているかを確認してください。

＜後編に続きます。＞