Browse Month: September 2009

Ruby Enterprise の RPM を作成する方法

Ruby Enterprise は、Passenger との相性がなかなかよいですが、Ruby Enterprise は tarball 形式しか配布されていないので、複数のサーバにインストールするのはなかなか不便です。

そこで、Ruby Enterprise の RPM を作ってみました。
基本的な方式は、Ruby Enterprise の通常のセットアップ方法(tarball を解凍してから、installer を実行する)にのとってみました。

作成した SPEC ファイルはここにおいておきますが、いくつか制限事項があります。

  • インストール先は、/opt/ruby-enterprise-バージョン-リリース日になります
  • インストール先へのシンボリックリンクを /opt/ruby として作成しています
  • RPM をビルドするサーバに、すでにインストール先のディレクトリがあるとエラーになります
  • アップグレードすると、インストール先が変わるので gem は再インストールすることになります
  • RPM をビルドするとき、インストール先のディレクトリオーナーをビルドしているユーザに変更していますので、sudo が必要です
  • rubylocal と ruby1.8-dummy というダミーパッケージが必要です(これは、REE の rpmbuild したときに行われる依存性チェックにひっかかるためです)
  • REE の installer スクリプトの –auto を使用してインストールしています

ダミーパッケージが必要になってしまうのと、rpmbuild で sudo しているところがなんとかしたいところですが、検索するとすでに作っている人がいたみたいなので、そちらを使ってもいいかもしれませんね。

いずれにしても、REE の公式のインストール方法にしたがった RPM を作ったので、複数のサーバにインストールするのが楽になりました。

CentOS 入門本を一部執筆しました

元同僚の人から声をかけてもらって、CentOS 入門本を一部執筆しました。個人的には、初めての著書になります。

タイトルは、

改訂第二版 CentOSサーバ構築バイブル

です。

マイコミさんから出版となりますので、公式ページはここ、目次はここにあります。

以下、本の概要になります。

サーバ用OSとして実績を誇る有償のRed Hat Enterprise Linux(RHEL)から知的財産物(ロゴなど)と商用パッケージを除いた無料のディストリビューションがCentOSです。
CentOSは新しいRHELリリース後に再構築され、きちんとしたテストを経てリリースされるので、安定性が確保され、また、パッケージの更新やセキュリティ面でのサポートも約束されているので
安心して利用を続けることができ、サーバ用途に最適です。
本書は、RHELと同等の機能・性能を持つ、CentOS5.3のインストール、システム管理、ネットワーク構築から各種サーバ運用までを判りやすく解説した書籍です。
CentOS5.3のi386版バイナリを収録したインストール用DVD-ROMとCDからCentOSをブート可能なLiveCDが本書に添付されます。

この本は、CentOS の初心者から中級者あたりを対象に CentOS のインストールから、各種サーバのセットアップ方法について一通り詳しく書かれている本です。

僕は、ウェブサーバ(Apache)とデータベース(MySQL と PostgreSQL)の二つの章を担当しました。

すでに CentOS をサーバとして使っている人には正直なところ新しい内容はほとんどないと思いますが、これから CentOS でサーバを構築しようとする人には幅広い内容をカバーしていますのでぴったりの本だと思います。816 ページというボリュームからも分かると思います。

Amazon で自分の名前で検索して検索結果があることに妙に感動しました!Suggest はされませんでしたが。あわせて、執筆という貴重な体験もさせていただきました。

この本を通じて、一人でも多くの人が CentOS でサーバを構築して日々の業務に役に立てていただければ幸いです。

ちなみに、僕も仕事で CentOS をサーバとしてサービスを提供していますが、CentOS を使っている理由は次のとおりです。

  • RHEL の無償版ということで、馴染みのある人が多いはずなので業務の担当者に説明がしやすい
  • Linux ディストリビューションの中では、かなりメジャーなので対応しているプログラムがかなり多い
  • Linux カーネルも含めて Redhat がサポートしている OS をベースとしているので、比較的安定性が高い
  • 本誌も含めて、CentOS の解説書はとても多いため、他の担当者に引き継ぎしやすい

もちろん、Linux カーネルや公式の yum リポジトリで提供しているパッケージのバージョンが枯れすぎていて古い、ちょっと前に話題になったプロジェクト問題がこれからもおきそうで不安、といった短所もあります。前者は自分で Linux カーネルをビルドしたり、自分で独自のパッケージを作ればさほど問題にならない、後者はおそらく大丈夫だと祈れば特に大きな障害にはなりません。

業務で使う以上、最後の理由はとても大きいです。もし、FreeBSD や OpenBSD を使ってしまうと、なかなか他の担当者に引き継ぐことは難しくなりますので。

ということで、そろそろ発売になりますが、興味のある人はぜひお手に取って読んでいただければありがたいです。

この歩んを通じて、一人でも CentOS でサーバを構築するきっかけになれば幸いです。

改訂第二版 CentOSサーバ構築バイブル
平 初 伊藤 幸夫 上鍵 忠志 中澤 直也 面 和毅 館林 綾ノ介 高安 洋輝 宇野 素史 坂井 恵
毎日コミュニケーションズ
売り上げランキング: 54464

DELL OMSA 2

先日の DELL OMSA の続き。いただいたコメントに、すばりな情報が公開されていたので、試してみました。

具体的には、/etc/redhat-release を次のように書き換える手順がやっていませんでした。DELL OMSA のセットアップシェルスクリプトでは、RHEL5 かどうか判定しているので CentOS 5.2 でも RHEL5 に見せかけることが必要です。CentOS release 5.2 という部分は、変更する必要もないのでそのままにしておいたほうがよいでしょう。

— /etc/redhat-release-org 2009-09-18 22:42:23.000000000 +0900
+++ /etc/redhat-release 2009-09-19 21:30:08.000000000 +0900
@@ -1 +1 @@
-CentOS release 5.2 (Final)
+CentOS release 5.2 (Final Tikanga)

これで、DELL OMSA の tarball を使う前にDellLinuxWikiに書かれている DELL が公式に提供している yum リポジトリを使ってできるのかなと試してみたところ、srvadmin-all というパッケージが見つかりません。ちょうど、友人も同じような DELL サーバをもっていて試してもらったところ、ちゃんちょ srvadmin-all というパッケージでインストールできたとのこと。友人の DELL サーバと比較すると、僕の DELL サーバの違いは、次の点です。

  • DELL サーバの機種が R200 でなく、R300
  • DRAC カードを搭載している
  • yum のバージョンが新しい

bootstrap.cgi の内容を見てみると、やっていることをいたって単純で /etc/yum.repos.d に dell-omsa-hwindep と dell-omsa-hw という yum リポジトリの設定を追加しているだけの様子。
srvadmin-all というメタパッケージは、dell-omsa-hwindep という yum リポジトリにある様子で、次の URL で取得している。

http://linux.dell.com/repo/hardware/latest/mirrors.cgi?osname=el$releasever&basearch=$basearch&sys_ven_id=$sys_ven_id&sys_dev_id=$sys_dev_id&dellsysidpluginver=$dellsysidpluginver

sys_ven_id と sys_dev_id と dellsysidpluginver という変数は、yum-dellsysid という yum プラグインで展開しているっぽい。展開されている具体的にな URL を調べる方法は分からなかったが、R300 の場合 smbios-utils というパッケージに含まれている /usr/sbin/getSystemId というコマンドで機種 ID を調べることができる。
smbios-utils というパッケージは、linux.dell.com で提供されているので、CentOS 5.x の場合は RHEL5 の RPM をインストールすればよい。

$ sudo /usr/sbin/getSystemId
Libsmbios version: 2.2.17
Product Name: PowerEdge R300
Vendor: Dell Inc.
BIOS Version: 1.2.0
System ID: 0x020F
Service Tag: XXXXXX
Express Service Code: XXXXXXXXZ
Asset Tag:
Property Ownership Tag:

System ID が 0x020F だということが分かるので、DELL OMSA 6.1 Linux Reposioty にずらっとあるディレクトリの中から、R300 の場合 system.ven_0x1028.dev_0x020f が選ばれて x86_64 が選択される仕組みになっているのだと思う。ここには、srvadmin-all というメタパッケージがある。

原因を調べてみたが局よく分からなかったし、すべてのサーバから linux.dell.com の yum リポジトリを参照するのはやめたいと思って、DELL OMSA の tarball を使うことにした。

DELL OMSA の最新版は 6.1 なので、tarball をダウンロードする。

$ wget http://ftp.us.dell.com/sysman/OM_6.1.0_ManNode_A00.tar.gz

ダウンロードした tarball を展開すると、その中に setup.sh があるので root 権限で実行する。なお、パラメータをつけないとライセンスの確認やインストールするコンポーネントの選択画面が表示されてしまうので、次のようにすべてのコンポーネントをインストールして時動的に起動するように実行すると便利。

$ sudo setup.sh –express –autostart

ちなみに DELL OMSA をインストールするには、次のパッケージが必要なので事前にインストールしておく必要がある。

  • compat-libstdc++-33
  • curl-devel
  • libxml2-devel
  • smbios-utils

setup.sh では、機種を判定しつつ、DRAC が搭載しているかもチェックして必要な RPM のみをインストールしてくれる。
インストール先は、/opt/dell 以下にインストールする。なお、DELL OMSA をアンインストールしたい場合は、展開したファイルの中の linux/supportscripts/srvadmin-uninstall.sh を実行すればいい。

DELL OMSA が起動すると、1311 ポートで https 経由で DELL OMSA の管理画面からサーバの情報を閲覧することができる。管理画面のアカウントは、CentOS 側のユーザ認証を PAM 経由で行っているので、CentOS に登録してあるユーザでログインすることができる。外部に接続しているサーバの場合には、セキュリティに注意したほうがよい。

DELL OMSA の管理画面の使い方は、この公式日本語ドキュメントを読んでみたほうがよい。

DELL OMSA は、GUI / CLI の二つの形式で、サーバに搭載されているデバイスやその状態を見ることができる。例えば、次のような情報を見ることができる。

  • 搭載 CPU の種類
  • メモリスロットごとのメモリ搭載容量
  • ハードウェア RAID の状態
  • ファンの回転数
  • 電源ユニットの状態
  • 温度
  • 電圧
  • DRAC

SNMP にも対応している。これでもかというくらいハードウェアの情報を取得できる。GUI は、次のような画面(公式日本語ドキュメントより)。

CLI のリファレンスは、ここにあって /opt/dell/srvadmin/oma/bin/ にインストールされている。

CLI で mpt-status を使用せずにハードウェア RAID の状態を取得できるか調べてみたところ、GUI の情報CLI の情報があった。
CLI で、ハードウェア RAID の状態を取得するには、omreport コマンドを使うとできる様子。
まず、使い方を見てみる。

$ sudo /opt/dell/srvadmin/oma/bin/omreport storage -?
Command Description
adisk Display array disk(s) properties. DEPRECATED: please use pdisk
pdisk Display physical disk(s) properties.
vdisk Display virtual disk(s) properties.
controller Display controller(s) properties.
enclosure Display enclosure properties.
battery Display battery properties.
globalinfo Display global storage properties.
connector Display connector properties.

battery があるってことは、BBU も搭載できるハードウェア RAID があるのかもしれない。コントローラ ID を調べる必要があるので、次のコマンドを実行する。

$ sudo /opt/dell/srvadmin/oma/bin/omreport storage controller
Controller SAS 6/iR Adapter (Slot 1)

Controllers
ID : 0
(以下、略)

物理ディスクの状態を取得してみる。

$ sudo /opt/dell/srvadmin/oma/bin/omreport storage pdisk controller=0
List of Physical Disks on Controller SAS 6/iR Adapter (Slot 1)

Controller SAS 6/iR Adapter (Slot 1)
ID : 0:0:0
Status : Ok
Name : Physical Disk 0:0:0
State : Online
Failure Predicted : No
(以下、略)

おぉー、mpt-status を使わなくてもハードウェア RAID の状態を取得できた。Status の部分をチェックするスクリプトを書くと nagios で監視することができそう。

他にも omreport コマンドを使うことでハードウェアの情報を取得できる。

$ sudo /opt/dell/srvadmin/oma/bin/omreport -?

omreport Reports component properties.

The available command(s) are:

Command Description
about Product and version properties.
system System component properties.
rac Command not supported. Use the racadm utility.
chassis Chassis component properties.
storage Display storage component properties.

rac というのは DRAC のことで、DRAC にはアクセスするには racadm ユーティリティを使うみたい。なるほど、これは便利。
こんなにできると DRAC は必要なかったのかもしれない。

ということで、DELL OMSA をすべての物理サーバに導入するために、次のような puppet マニフェストを書いてみた。次の点がポイントになっている。

  • dell-omsa というパッケージは、DELL OMSA の tarball をインストールするだけの独自パッケージ
  • tarball だけにしている理由は、tarball で約 104MB もあるので展開した RPM を作ったら約 1.1GB の RPM になってしまったから
  • /etc/redhat-release は、CentOS のバージョンが違うことがあってファイルの置き換えはできないので sed で頑張ってみた

class dell {
file { “/etc/redhat-release”:
content => “$operatingsystem release $operatingsystemrelease (Final Tikanga)”,
}

package { “dell-omsa”:
notify  => File[“/opt/dell-omsa/setup”],
}

file { “/opt/dell-omsa/setup”:
ensure => directory,
notify => Exec[“dell-omsa-extract”],
}

exec { “dell-omsa-extract”:
command     => “tar xzf /opt/dell-omsa/dell-omsa.tar.gz -C /opt/dell-omsa/setup”,
notify      => Exec[“dell-omsa-setup”],
require     => File[“/etc/redhat-release”],
refreshonly => true,
}

exec { “dell-omsa-setup”:
command     => “/opt/dell-omsa/setup/setup.sh –express –autostart”,
refreshonly => true,
}
}

あとは、GUI でも見れるようにプロキシ経由して設定する予定。

自作サーバもよいけれど、メーカーのサーバだとこういったソリューションが用意されていれて、それはそれで便利だと思った。

# 2009.09.22 追記

いただいたコメントをもとに puppet の manifest を修正しました。

tarbar を展開するリソースは作った方が便利かもしれない。

# 2009.09.23 追記

puppet の manifest を再修正した。

attachment_fu プラグインでアニメーション GIF を正しくリサイズする方法

Rails で画像をアップロードするとき、attachment_fu プラグインがとても便利です。

しかし、attachment_fu プラグインでは、アニメーション GIF をアップロードすると静止画だけになってしまいます。

対策を調べたところ、Resizing animated gif on attachment_fu’s Rmagick というずばりなブログが見つかり一行直すだけで対応できそうだと思って変更してみました。しかし、この変更では正しくリサイズされませんでした。

正しくアニメーション GIF をリサイズするには、ImageMagickでGIFアニメをリサイズ を参考にしつつ RMagick を使うと、次のようなコードになります。

require ‘rubygems’
require ‘Rmagick’

source_path = “変換対象の GIF”
dimension = “400×200>”
result_path = “変換後の GIF”

img = ::Magick::ImageList.new(source_path)
img = img.coalesce()
img.each { |frame|
frame.change_geometry!(dimension) do |c, r, i|
i.resize!(c, r)
end
}
img.write(result_path)

この実装を attachment_fu プラグインに組み込まないとうまくいかないことが判明して、さらに調査してみるとズバリの変更が DianthuDia さんの github にありました。

さっそく、attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb を変更してみたところ、アニメーション GIF をアップロードしたとき正しくリサイズできるようになりました!ただし、フレームが何枚もあるアニメーション GIF だと対象アップロードに時間がかかるので注意してください。

attachment_fu プラグインでは、RMagick 以外でも使えるのですが、アニメーション GIF のサポートをするには必ず RMagick を使う必要があるので、次のように processor を設定する必要があります。

has_attachment :processor    => ‘Rmagick’,
:content_type => :image,
:storage      => :file_system,
:max_size     => 1.kilobyes,
:resize_to    => “400×200>”

これで、ようやく attachment_fu プラグインを使ってアニメーション GIF もアップロードすることができるようになりました。もちろん、アニメーションではない GIF も正しくリサイズされます。

MySQL Cluster セミナーのレポート

Sun が主催した MySQL Cluster セミナーに行ってきました。普段、MySQL Community Server を使用していますが、MySQL Cluster を実際に使われている貴重なセミナーのため参加してみました。

MySQL ダウンロード数: 893,092 DL(過去1年間、Windos 版が一番多い)
MySQL Cluster 7.0: 2009年4月 GAリリース
MySQL 5.1 2008年 GAリリース
MySQL 5.4 2009年 プレビュー版リリース

今回のセミナーは、次のとおり。

  • MySQL Cluster 7.0 の紹介 by Sun
  • MySQL Cluster 7.0 に最適な Sun の x86 プラットフォーム by Sun
  • MarketSpeed における MySQL Cluster 適用事例紹介 by 楽天証券
  • MySQL Cluster 導入のケーススタディ by 住商情報システム株式会社

MySQL Cluster 7.0 の紹介

無償と有償で、できるものがある。

無償
ライセンスは、GPL

  • MySQL Community Server
  • MySQL Cluster Community(OSS) Edition
  • MySQL GUI 管理ツール
  • MySQL コネクタ(JDBCなど)
  • ドキュメント
  • フォーラム

有償

  • MySQL Enterprise
  • MySQL Enterprise Unlimited(サーバ台数無制限)
  • MySQL Cluster: Standard Edition, Carrier Grade Edition
  • トレーニング
  • プロフェッショナルサービス

MySQL Enterprise は、MySQL Community Server の機能はまったく同じで、付加価値をつけての有償契約になっている。モニタリングツール、MySQL Query Analyzer、など。MySQL Query Analyzer は、時間別にクエリーの内容などを見ることができる。

MySQL Cluster の特徴は、次のとおり。

  • シェアードナッシング型クラスタ
  • コスト: 共有ディスクや特別なハードウェアは不要
  • 耐障害性: SPOFなし(素敵!)
  • 高可用性: 複数のノード(データノード)に同期型レプリケーションで記録される
  • 自動的にフェイルオーバー
  • スケーラビリティ: 参照は、コピーされた複数のデータノードで参照される
  • 高性能
    – インメモリデータベース(ディスクへのデータ格納も可能)
    – 100,000 QPS のリクエストに対応する
    – マルチスレッド対応

MySQL Cluster と MySQL Enterprise は、まったくの別々の製品になっている。

MySQL Cluster のコンポーネントは、次のとおり。

SQL Node
– 標準的な SQL インターフェース
NDB API
– 組み込み用途などに向けた高いパフォーマンスが必要なときに使える
– C++ API として使える
Data Node
– データストレージ(ディスクあるいはメモリ)
– 自動的なパーティショニング
– 同期型なので、どの Data Node にもまったく同じデータがあることを保証されている
– ディスクには、メモリ上の REDO ログバッファに記録されたトランザクションをディスク上の REDO ログファイルに書き出す(書き出す実行間隔は、デフォルトは 2000ms になっているが設定可能)
Management Node
– 管理および設定
– 2ノードでの可用性

JOIN をしたい場合、MySQL Cluster 単独ではパフォーマンスがでないため、MySQL Cluster から MySQL Community Server に非同期レプリケーションした先で行うことができる。

MySQL Cluster の有償ライセンスは、Standard Edition と Carrier Grade Edition の二種類ある。動的なノード追加は、Carrier Grade Edition のみで利用可能。

MySQL Cluster のベンチマークとして DBT2 を使ったベンチマーク結果が、ここで公開されている。

MySQL Cluster 7.0 に最適な Sun の x86 プラットフォーム

タイトルのとおり、Sun x86 プラットフォームの紹介。
AMD/Intel 両方のハードウェアがある。メモリスロット数は、AMD CPU x 2 で 16 スロット、Intel CPU x 2 で 8 スロットある。ベンダーによっては、メモリスロット数が少ないという情報があったので注意したい。サーバのハードウェア障害が発生する箇所として、電源、ファン、ハードディスク、がほとんどのこと。Sun のサーバは、SSD を搭載可能。

楽天証券での MySQL Cluster 事例

※このセッションは、極秘のため非公開にしないといけなくなりました。残念です。

MySQL Cluster 導入のケーススタディ

※このセッションは、楽天証券のケーススタディとして取り上げられていたので非公開にしておきます。また、資料は別途修正して公開される予定とのことでした。

MySQL Cluster は、まったく使ったことはなかったけれど、今回のセミナーで概要を把握できたのでよかった。

MySQL Cluster は、基本的にはインメモリデータベース、SPOF なし、JOIN などのクエリーに弱い、などかなり大きなクセがあるので、本番へ導入するにはかなり要注意だと思った。楽天証券でも、テストの段階でいろいろとはまって、サポートしてもらったそうだ。

このことから、僕が担当しているサービスに MySQL Community Server のかわりに MySQL Cluster を導入するのは、次の点でかなり敷居が高いと思った。

  • 物理メモリを多く搭載しているサーバが必要(インメモリデータベースなので、サーバ1台のコストアップにつながる)
  • 個人的にクラスターソリューションを導入した経験がまったくないので、導入・検証・運用などにおいて別途サポート契約が必須であること(おそらくけっこうなコストがかかると想定される)
  • JOIN のクエリがけっこうある
  • MySQL Cluster は仮想化に未対応なので、少なくても Data Node 2 台、Management Node 2台は物理的に必要であること(さらにいうと SQL Node も別のサーバにする場合は、さらに物理的なサーバ台数が必要)

今の段階では上のような考察にはなるが、ミッションクリティカルなシステムを担当しているので、かなり興味深いソリューションであることは間違いないので、引き続きウォッチしていきたい。

データベースまわりでは、DB Magazine 今月号を読んでそろそろ SSD を導入するのは、かなり現実的であると思っています。

cron の実行順序を制御する方法

cron のバッチ処理の実行順序を制御するときは、setlock を使うと便利そうだったので、設定してみた。この方法では、setlock に setlock を設定している理由がよく分からなかったので、何はともわれ試してみた。

setlock についてのヘルプは、こちら

まず、daemontools の RPM は、daemontools.spec を使うとすぐに作ることができる。daemontools は、/usr/local/bin にインストールされる。

次に、バッチ処理に見立てた簡単な次のプログラムを準備する。

1.rb: 一番最初に実行される毎時バッチ

#!/usr/bin/env ruby
require ‘date’
p “#{__FILE__} start #{DateTime.now}”
sleep 120
p “#{__FILE__} end #{DateTime.now}”

2.rb: 1.rb の次に実行される毎時バッチ

#!/usr/bin/env ruby
require ‘date’
p “#{__FILE__} start #{DateTime.now}”
sleep 60
p “#{__FILE__} end #{DateTime.now}”

3.rb: 2.rb の次に実行される毎日バッチ

#!/usr/bin/env ruby
require ‘date’
p “#{__FILE__} start #{DateTime.now}”
sleep 30
p “#{__FILE__} end #{DateTime.now}”

やりたいことは、これからの 1.rb, 2.rb, 3.rb を順番に一つずつバッチを実行したい。

次にテスト用に、近い将来の時間で実行されるように cron を、次のように設定する。

55 22 * * * /usr/local/bin/setlock -nx /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/1.rb
55 22 * * * /usr/local/bin/setlock /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/2.rb
55 22 4 * * /usr/local/bin/setlock /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/3.rb

そして、メールが3通 root 宛に届くので、そのメールをみてちゃんとそれぞれのバッチの実行順序が制御できるか調べた。

次のメールが2通きた。

“/tmp/3.rb start 2009-09-04T22:55:02+0900”
“/tmp/3.rb end 2009-09-04T22:55:32+0900”

“/tmp/2.rb start 2009-09-04T22:55:32+0900”
“/tmp/2.rb end 2009-09-04T22:56:32+0900”

1.rb は実行されていない!?と思ったら、-n オプションをつけているので当り前だった。/var/log/cron をみると、次の順序で実行されていた。

3.rb

2.rb

1.rb

なるほど、同時刻に実行される cron の実行順序は crontab に書いてある順とは逆のような気がするが、今度は次のように1分ずらして設定してみた。

26 23 * * * /usr/local/bin/setlock -nx /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/1.rb
27 23 * * * /usr/local/bin/setlock /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/2.rb
28 23 4 * * /usr/local/bin/setlock /tmp/local_cron.lock /usr/local/bin/setlock /tmp/all_cron.lock /tmp/3.rb

そうして、次のメールが3通きた。

“/tmp/1.rb start 2009-09-04T23:26:01+0900”
“/tmp/1.rb end 2009-09-04T23:28:01+0900”

“/tmp/2.rb start 2009-09-04T23:28:01+0900”
“/tmp/2.rb end 2009-09-04T23:29:01+0900”

“/tmp/3.rb start 2009-09-04T23:29:01+0900”
“/tmp/3.rb end 2009-09-04T23:29:31+0900”

1.rb でウェイトを 120 秒おいているので、正しく順番に実行されているのが分かる。

でも、どうしてわざわざ setlock に setlock しているのか、理由がよく分からない。setlock は単にファイルのロックができるどうかを待つだけのシンプルなプログラムなので、二重化する必要性がよく分からない。

試しに setlock を一つだけにしてみても、同じ実行順序で制御できていたので、設定はシンプルな方がミスも少ないし特に問題だと思わなかったので、本番環境へ時間を明示的にずらして setlock を付与してみた。時間を明示的にずらしておいたほうが、視覚的にその時間で順番に実行されるというのが分かるのでいいかなと思った。

DELL スイッチの選び方

コストパフォーマンスと重心して、DELL スイッチ 48 ポートをよく使っているけれど、DELL スイッチにはノンインテリジェントスイッチの PowerConnect 2748ノンインテリジェントスイッチの PowerConnect 5448 があるので、オンラインページの情報を元にそれぞれのスイッチの仕様の違いを勝手にまとめてみた。オンラインページで比較検討できると最高なんだけれどな。

PowerConnect 2748 PowerConnect 5448
オンライン構成例価格 100,275円 157,500円
主な特長 Webインターフェースにて以下の機能をサポート
VLAN機能:IEEE802.1Q(ポート、タグベース)準拠(最大64VLAN)
リンクアグリゲーション、LACP機能:IEEE802.3ad準拠(4ポート/1リンク、6リンク/1ユニット)
QoS:IEEE802.1p, DSCP, 4 Priority Queues/ポート
8000MACアドレスに対応
プラグ&プレイ型としても使用可
iSCSI 最適化 (高優先度の最適化)
Webインターフェース及びCLI(コマンドラインインターフェース)をサポート
VLAN機能:IEEE802.1Q(ポート、タグベース)準拠(最大4000VLAN)
リンクアグリゲーション、LACP機能:IEEE802.3ad準拠(8ポート/1リンク、8リンク/1ユニット)
スパニングツリー機能:IEEE802.1D準拠
ラピッドスパニングツリー機能:IEEE802.1w
マルチプルスパニングツリー機能:IEEE802.1s
QoS:IEEE802.1p, DSCP, 4Priority Queues/ポート
Multicast:Static IP multi-cast; IGMP snooping
電源2重化対応:RPS-600使用時
セキュリティ:IEEE802.1x準拠, IP,MACアドレスベースACL
8000MACアドレスに対応
スイッチ容量 144Gbps 96Gbps
転送能力 71.4Mpps 96Gbps
ポート構成 48x 10/100/1000BASE-T
4x SFPスロット(1000BASE-SX/LX):コンボポート
48x 10/100/1000BASE-T
4x SFPスロット(1000BASE-SX/LX):コンボポート
オプション SFPトランシーバー(1000Base-SX/LX) SFPトランシーバー(1000Base-SX/LX)
RPS-600(冗長化電源)

こんな感じの仕様の違いになっています。どちらもウェブ経由の管理画面があって、スイッチの設定をいろいろと変更できる。管理画面のスクリーンショットは、次のとおり。当然ながら、インテリジェントスイッチの方が項目が多い。

PowerConnect 2748

PowerConnect 5448

ほぼ仕様は同じだが、一番大きな違いに CLI(コマンドラインインターフェース)のサポートの違いがある。CLI を使うと、スイッチの各ポートの状態を把握しているのでよくあるといわれているスイッチのあるポートが故障しているか事前にチェックすることができるのが多い。値段はすこし高いが、この機能のサポートでインフラの中でもかなり重要なスイッチの故障が検出できるのはとても大きい。ミッションクリティカルなシステムには、PowerConnect 5448 を使った方が安心だろう。

具体的には、PowerConnect 5448 で IP アドレスの設定をすれば telnet/SSH などでアクセスすることができる。例えば、1番ポートの状態をみるには、次ようなコマンドを実行する。expect を使って、telnet で接続して、時刻、vlan、をまとめて設定するシェルスクリプトである。

$ telnet <switch の IP アドレス>

User Name: admin

Password: <パスワード>

# sh int status

Flow Link          Back   Mdix
Port     Type         Duplex  Speed Neg      ctrl State       Pressure Mode
——– ———— ——  —– ——– —- ———– ——– —-

g1      1G-Copper    Full    1000  Enabled  Off  Up          Disabled On

コマンドのヘルプは、? を入力すると表示することができる。スイッチの設定を、すべてコマンドでできるのでかなり便利である。ただし、電源をオフオンしてしまうと VLAN などの設定が消えてしまうのを作った。そこで、次のようなスイッチの設定をするシェルスクリプトを書いてみた。

#!/bin/sh

if [ x”$1″ = “x” ]; then
echo “Usage `basename $0` ”
exit -1
fi

SWITCH_ID=$1
HOSTNAME=
USER=admin
PASSWORD=”password”
SNTP_SERVER=

expect -c ”
set timeout 5
spawn telnet $HOSTNAME
expect \”*User Name:\”
send \”$USER\r\”
expect *password:
send \”$PASSWORD\r\”

expect *#
send \”configure\r\”

expect *#
send \”hostname $HOSTNAME\r\”

expect *#
send \”clock source sntp\r\”
expect *#
send \”clock timezone +9 zone JST\r\”
expect *#
send \”sntp unicast client enable\r\”
expect *#
send \”sntp server $SNTP_SERVER\r\”

expect *#
send \”vlan database\r\”
expect *#
send \”vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g41\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g42\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g43\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g44\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g45\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g46\r\”
expect *#
send \”switchport mode access\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g39\r\”
expect *#
send \”channel-group 1 mode on\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g40\r\”
expect *#
send \”channel-group 1 mode on\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g47\r\”
expect *#
send \”channel-group 2 mode on\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface ethernet g48\r\”
expect *#
send \”channel-group 2 mode on\r\”
expect *#
send \”exit\r\”

expect *#
send \”interface port-channel 2\r\”
expect *#
send \”switchport access vlan 2\r\”
expect *#
send \”exit\r\”

expect *#
send \”exit\r\”

PowerConnect 5448 でよいかなと思ったら、このモデルだと IP アドレスごとにタグ VLAN を付与することができないことを知った。当り前だといえば当り前なので、やっぱり L3 スイッチがよさそうである。DELL の L3 スイッチは PowerConnecr 6248 という製品に該当する。マニュアルをみるかぎり、IP アドレスごとにタグ VLAN を付与できるので、サーバ/インフラ本に書いてあったどのポートに接続しても大丈夫な構成ができるはず。さらに VRRP もサポートしているので、2台用意してスイッチのアクティブ/バックアップの構成ができそうな感じである。

# でも、他のラックを見てみると、みんな Cisco なので、やっぱり Cisco ということでしょう!!! ちゃんちゃん。