Browse Tag: server

オンプレサーバで MAC アドレスを IPMI 経由で取得する方法

オンプレサーバの場合、OS をインストールするには、事前に MAC アドレスが分からないと、自動的にネットワークインストールして OS をインストールすることができません。

今まで使ったことがある二つのメーカーについて、IPMI 経由でオンボード NIC の MAC アドレスを取得する方法を紹介したいと思います。そのため、事前い IPMI の IP アドレスなどを設定しておくことが前提条件となります。

SuperMicro

公式情報は、こちらにあります。


$ ipmitool -I lanplus -H -U raw 0x30 0x21
※パスワードを入力します

ここで表示された 10 バイト取得した値のうち、最後から 6 byte までは LAN1(eth0) の MAC Address、LAN2(eth1) は最後のバイトに 1 足したものになります。

HP ProLiant

HTTP で XML 情報を取得すると、その中に含まれています。EC2 みたいで、便利ですね!


$ curl https:///xmldata?item=all -k

で出力される XML の中の MACADDR 要素が MAC アドレスとなります。

Chef のパッケージをまとめてダウンロードする

Chef のパッケージをインストールするとき、通常は次の方法が公式サイトにて紹介されています。

$ curl -L https://www.opscode.com/chef/install.sh | sudo bash

たしかにこの方法でインストールすることが出来るんですが、パッケージのあるサイトが海外の S3 のため、非常に遅いので、まとめてダウンロードするプログラムをさくっと書いてみました。

プログラムは、次のような感じです。
例えば、EL5 用のパッケージをダウンロードしたいときには、次のコマンドを実行するだけです。

$ ruby get_packages.rb el5

これで実行カレントディレクトリにパッケージがまとめてダウンロードされます。ただし、ベータ版や i386 パッケージは除外しています。
あとは、このパッケージをまとめて yum リポジトリとかにすると便利ですよね。


#
# get_packages.rb
#
require 'net/http'
require 'rexml/document'

case ARGV[0]
when 'el5', 'el6', 'deb'
package = ARGV[0]
else
p 'Usage: get_packages.rb '
exit 1
end

baseurl = 'opscode-omnibus-packages.s3.amazonaws.com'

# get the XML data as a string
xml_data = Net::HTTP.get_response(URI.parse('http://' + baseurl)).body
doc = REXML::Document.new(xml_data)

Net::HTTP.start(baseurl) do |http|
doc.elements.each('ListBucketResult/Contents/Key') do |v|
# x86_64 packages only, exclude rc git packages
next if v.text =~ /^.*(git|rc|alpha|beta).*$/
case package
when 'el5'
next if v.text !~ /^.*.el5.x86_64.rpm$/
when 'el6'
next if v.text !~ /^.*.el6.x86_64.rpm$/
when 'deb'
next if v.text !~ /^.*amd64.deb$/
end

package_name = File.basename(v.text)
next if File.exist?(package_name)

puts 'Downloading ' + v.text
resp = http.get('/' + v.text)
open(package_name, 'wb') { |file|
file.write(resp.body)
}
end
end
puts "Done"

cobbler web を nginx 経由で使う方法の続き

http://www.sssg.org/blogs/naoya/archives/2495 で紹介した方法ですが、肝心の /cblr/svc/ 以下の uswsgi の設定が抜けていたのでご紹介します。

まず、uWSGI が必要なので、コンパイルします。

今回は、1.9 系の最新版を使ってみます。

# yum install python python-devel libxml2 libxml2-devel python-setuptools zlib-devel wget openssl-devel pcre pcre-devel sudo gcc make autoconf automake -y
# wget http://projects.unbit.it/downloads/uwsgi-1.9.21.1.tar.gz
# tar zxf uwsgi-1.9.21.1.tar.gz
# cd uwsgi-1.9.21.1
# python setup.py build
# make

make すると、カレントディレクトリに uwsgi プログラムができるので、これを利用します。

cobbler の /cblr/svc 以下や cobbler web 用の uwsgi は、次のコマンドで起動します。

# /usr/sbin/uwsgi --wsgi-file /var/www/cobbler/svc/services.py --socket 127.0.0.1:9090 --processes 4 --master --harakiri 120
# /usr/sbin/uwsgi --wsgi-file /usr/share/cobbler/web/cobbler.wsgi --socket 127.0.0.1:9091 --processes 4 --master --harakiri 120

手動で起動する場合は、supervisord を利用すると便利ですね。

これで、http:///cblr/svc/op/ks/system/s1 とかで、サーバの kickstart を参照できますね!

cobbler をインストールすると、Apache HTTPd も一緒にインストールされるので、ポートが競合しないようにしましょう。

Ubuntu で正しく Ruby 1.9.3 をインストールする方法

Ubuntu Server 12.10 で Ruby 1.9.3 を System Ruby として使いたい場合 ruby1.9.3 というパッケージをインストールするだけです。


$ sudo apt-get install -y ruby1.9.3

しかし、/etc/alternatives 以下が 1.9.1 のままとなってしまいますので、ruby1.9.3 をインストールしたあとで、次のコマンドを実行すると正しくなります。
なお、このコマンドを実行しなくても、見た目上は正しく Ruby 1.9.3 に上書きされているので問題ないかと思います。


$ sudo update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.9.3 500 \
--slave /usr/bin/ri ri /usr/bin/ri1.9.3 \
--slave /usr/bin/irb irb /usr/bin/irb1.9.3 \
--slave /usr/bin/erb erb /usr/bin/erb1.9.3 \
--slave /usr/bin/rdoc rdoc /usr/bin/rdoc1.9.3
$ sudo ln -sf /usr/bin/gem1.9.3 /etc/alternatives/gem
$ sudo ln -sf /usr/share/man/man1/gem1.9.3.1.gz /usr/bin/gem.1.gz

参考
Ruby 1.9.3 on Ubuntu 11.04

GNU Parallel を本番環境で使ってみました

GNU parallel を本番環境で使ってみました。
本番環境では、10 台程度ある Apache のウェブサーバのアクセスログを mod_log_rotate で 1 時間ごとに出力して、バッチ処理のサーバで集めています。

最初は、シェルスクリプトで、次のようにしていました。
次の例はウェブサーバが s1 〜 s10 まであって、$LOG_DIR/$LOGFILE に 1 時間ごとに出力したアクセスログがあると想定しています。当然ながら、下記のシェルスクリプトの実行ユーザで対象のサーバへ SSH 経由に接続できるものと想定しています。


for s in s1 s2 s3 s4 s5 s6 s7 s8 s9 s10; do
ssh -q $s "test -f $LOG_DIR/$LOG_FILE"
RETVAL=$?
if [ $RETVAL -eq 0 ]; then
rsync -az -e "ssh -q" $s:$LOG_DIR/$LOG_FILE-$s
fi
done

対象のサーバごとに順番に rsync しているため、対象サーバが増えるごとに rsync する時間がかかってしまいます。
10 台の場合、約 1 分 30 秒ほどかかっていました。
そこで、「GNU Parallelがすごすぎて生きるのがつらい – As a Futurist…」を参考にしながら、次のように並列で rsync するようにしてみました。


parallel -j +0 'rsync -azq -e "ssh -C -c arcfour -q" {}:$LOG_DIR/$LOG_FILE-{}' ::: s1 s2 s3 s4 s5 s6 s7 s8 s9 s10

GNU Parallel を使うとワンライナーで済んでしまいます。実際には、rsync に失敗することがあるので、3回ほどリトライ処理を行っています。
「-j +0」の部分は、お使いのサーバの CPU コア数などによって調整してください。
これによって、今まで 1 分 30 秒かかっていましたが、GNU Parallel を使ったバージョンだと 10 秒程度で終わるようになりました。これなら、ウェブサーバが増えても処理時間の延びを減らすことができそうです。

インフラエンジニアであるか見分ける10の質問

もし、自分ならこういう質問するかなと思ったものをあげてみたので、かなり偏見のある内容になっています。

  1. 今まで自身で構築したサーバの種類と、その構築方法について説明せよ
  2. サーバ用途で使用するオペレーティングシステムの種類と、その特長について説明せよ
  3. スケールアウトとスケールアップの違いを説明せよ、またそれぞれどのような長所・短所があるのか説明せよ
  4. システムを運用する上で、どのようなモニタリング(いわゆる監視)が必要な説明せよ、またその際に使用する具体的なアプリケーションとその特長をあげよ
  5. ハードディスクと SSD の内部構造の違いについて説明せよ、またそれぞれどの場面で使うと有効であるか説明せよ
  6. SSH を設置するために、セキュリティ的な観点で気をつけなければならない点をすべてあげよ
  7. 自前インフラとクラウドインフラ、それぞれの特長(長所・短所)を説明せよ
  8. TCP と UDP のプロトコル上の違いを説明せよ、また具体的にそれぞれのプロトコルを一般的に使用しているアプリケーションをあげよ
  9. (具体的に高負荷になっているサーバを例に出して)このサーバが高負荷となっているその理由、あわせてその対策を説明せよ
  10. (僕が運用しているシステムを例に出して)このシステム構成での問題点、および近い将来に問題となるであろう点がどこかであるかその理由と、その対策をあわせて説明せよ

 

うーん、もうすこし絞れそうな気がしますが、なかなか難しいですね><

 

(おそらく)サーバをたくさん並べるのは流行らない

これからの時代、(おそらく)サーバをたくさん並べるのは流行らないと思っています。

その理由は、次のとおりです。

  • 最近のサーバには、かなりの大量のメモリが搭載できる
  • CPU の処理速度もマルチコア化がかなり進んでいて上がっている
  • 仮想化技術が当たり前のようになっていてサーバのリソースをまんべんなく使えるようになっている
  • 最初のボトルネックになりがちだったディスクも SSD や Fusion I/O を搭載できる
  • ラックの最大許容電力の問題

具体的な例をあげてみましょう。いつもこのブログでは DELL サーバを例にとっているので、今回は HP のサーバを例にとってみます。

例えば、HP の ProLiant DL360 G7 では、最大次のような仕様になっています。

  • サイズ: 1U
  • CPU: Xeon 5500/5600番台 x 2
  • Memory: 192GB (DDR3、18 スロット)
  • Disk: 2.5 SAS/SATA x 8
  • NIC: 4ポート
  • PCI Express: 2 スロット

このサーバを、次のスペックで見積もってみると、約67万円くらいでした。

  • CPU: Xeon L5520 x 2
  • Memory: 48GB
  • Disk: 120GB 2.5 inch x 2

いっけん高いようにみえますが、比較するべきは、次のようなスペックのマシンを2台購入したときとのコストの比較になると思います。

  • CPU: Xeon L5520 x 1
  • Memory: 24GB
  • Disk: 120GB 2.5inch x 1

もちろん、マシンは機械である以上故障はするので、故障のリスクも考えないといけませんが、できる限りマシンは減らした方がサーバの運営管理コストは下がるので、量と質の問題を考えなければいけません。

さらに、4U の ProLiant GL580 G7 というサーバには、メモリをなんと最大 1TB まで搭載できます。コストは相当なかかると思いますが、コストはイニシャルコストとランニングコストのバランスの問題になってくるはずです。

すこし前までは、メモリが足りない、ディスクが遅い、などの理由で、多数の 1U サーバを並べる傾向が強かったような気がしています。

さらにクラウドでも、同じような傾向があります。クラウド大手の Amazon EC2 をみてみると、High Memory Instance として次の 3 種類が提供されています。

  • High-Memory Extra Large Instance 17.1 GB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform
  • High-Memory Double Extra Large Instance 34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
  • High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

Quadruple Extra Large を選択すると、なんと 68.4GB メモリが搭載されています。

価格は、現時点で次のとおりです。(US – N.California, Linux の場合)

  • Extra Large: $0.57 per hour
  • Double Extra Large: $1.34 per hour
  • Quadruple Extra Large: $2.68 per hour

Extra Large と Quadruple Extra Large の価格差は約 4.7 倍程度で、おおよそ実際のスペックと同じ比率になっています(若干すこし高めの設定ですが)。

この価格なら、例えば Extra Large を 5 台並べるか、Quadruple Extra Large を 1 台にするか、どちらがいいのか考える必要があるでしょう。

もちろん、サーバが少ないときのデメリットも、サーバが1台ダウンしたときの影響が大きいが考えられます。

すこし前まではサーバの多く並べる傾向が強かったと思います。

ただ、これからの時代はどちらかというと、サーバをたくさん並べるよりも、処理能力の高いサーバを少なく並べる傾向が強くなってくると思います。

つまり、僕はできる限り多くの同時リクエストを1台のサーバでさばく、そんな時代になってくると思うので、その流れにあった技術を身につけるのが重要になるのではないかと思います。

サーバの消費電力 -NEC サーバ編-

いつも、DELL サーバばかりのエントリばかりだったので、今回は久しぶりに違う内容をエントリします。

NEC サーバの 1U サーバの NEC Express 5800 シリーズの 2 種類の消費電力を測定する機会があったので、計測結果を紹介します。

計測方法は、前回の DELL サーバのときと同じクランプメーターで測定しました。

NEC Express 5800/R120a-1

  • CPU: Intel Xeon X5570 2.93GHz x 2
  • Memory: 32GB
  • HDD: Seagate Savvio ST973452SSS SAS 60GB x 6 (ハードウェア RAID 0)
  • Power: 冗長電源付き(2系統に電源が入っている場合、方側の電源を抜くともう片側に2倍の電力がかかる)
  • 消費電力 idle: 0.86A
  • 消費電力 max: 1.74A

NEC Express 5800/120Rh-1

  • CPU: Intel Xeon E5420 x 1
  • Memory: 8GB
  • HDD: Western Digital SATA 160GB x 1
  • Power: 冗長電源なし
  • 消費電力 idle: 1.76A
  • 消費電力 max: 2.10A

Xeon E5420 は、Intel のホームページを見ると 80w ですが、かなり消費電力が高いのが、特徴的でした。

サーバ本体の価格、消費電力、どちらをとるのか、サーバの用途によって決めていくのが重要だと思う今日この頃です。