Splunk 6 にバージョンあげてハマったこと(メモ)

地味にハマったので忘れたときようにメモ

libjemalloc.so.1 が足りないと言われて起動しない

ライブラリへのパスが通っていないと起こる。
パスを通してあげるとあっけなく起動する。

$ export LD_LIBRARY_PATH=/opt/splunk/lib

$ source /opt/splunk/bin/setSplunkEnv

$ /opt/splunk/bin/splunk start

 

IPv6 で WebIF が見れない

以下の conf をいじる

$ vi /opt/splunk/etc/system/default/web.conf

listenOnIPv6 = yes

 

debパッケージで入れたのに・・・チ●ショウ!

 

NSD4 beta4 vs BIND9.8.1 ~NSDの逆襲~

前回の POST で BIND からの NSD4 の移行について書いたのだが、
その際にテスト程度に走らせたベンチマークについて物議を呼んだので
(NSDがBINDなんかに負けるはずが無い!とか config煮詰めろとか)
NSD4 側の config をいじりながら再度ベンチマークを取ってみた。

そうしたところ、とても興味深い結果が得られたので記しておく。

 

0. 検証環境

CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping 07 × 2

Memory : DDR3 1333 NonReg ECC 16GB

HDD : 146GB 15000rpm SAS RAID 1

OS : Ubuntu 12.04.2

DNS : NSD4 beta4 / BIND9.8.1 -P1(Ubuntu Packege)

 

1. ベンチマーク方法

ベンチの方法は前回と同様に 32110行のクエリを dnsperf に食わせて行う。
クエリを飛ばす側のマシンも上記とほぼ同様のスペックで用意した。

コマンドは下記のとおり。

 # dnsperf -c 16 -s 10.200.4.230 -d querylist -l 300

※10.200.4.230 は被験体

  • nsd.conf の server-count を変更しながらベンチマーク
  • 16クライアント(並列)で300秒クエリを飛ばす

server-count はリクエストを受け付ける nsd の子プロセスの数なので、
多ければ多いほどクエリを捌けるはず(素人考え)

config は下記のとおり Rate limit は Off にしておく。

server:
server-count: 4
username: nsd
zonesdir: “/etc/nsd4/zones”
zonelistfile: “/var/cache/nsd4/zone.list”
database: “/var/cache/nsd4/zone.db”
logfile: “/var/log/nsd4.log”
pidfile: “/var/run/nsd4/nsd4.pid”
xfrdfile: “/var/cache/nsd4/xfrd.state”
rrl-ratelimit: 0
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: “/etc/nsd4/nsd_server.key”
server-cert-file: “/etc/nsd4/nsd_server.pem”
control-key-file: “/etc/nsd4/nsd_control.key”
control-cert-file: “/etc/nsd4/nsd_control.pem”

 

2. ベンチマーク結果

 

表1 BIND と NSD4 の qps 比較

 Server (server-count) qps
BIND9.8.1 -P1 362923.554683
NSD4 b4 (1) 237789.686302
NSD4 b4 (2) 287640.556382
NSD4 b4 (4) 409956.827579
NSD4 b4 (6) 178863.252545
NSD4 b4 (8) 129717.122177
NSD4 b4 (16) 70822.115927

 

nsd4_svcount
図1 NSD4 beta4 server-count と qps

nsd_bind_comp

図2 ベンチマーク中のロードアベレージの推移 (NSD4 beta4/BIND9.8.1-P1)

3. 考察

今回の実験では NSD4の server-count を 4 にした場合は最もパフォーマンスがよく、
サーバへの負荷(ロードアベレージ)も低目の値を推移している。
これはゾーンをバイナリ化してメモリに保持している効果と思われる。

また、当初想定していた結果とは異なり、server-count の値と qps は比例しないという結果が出たのが興味深い。
ハードウェア(CPU) 依存の可能性もあるので、AMD製のCPUなどでも試してみようかと思う。

BIND に関しては qps  で言うと NSD4 に匹敵する値をたたき出しているが、ロードアベレージが高めを推移している。
コスト的にはあまりお得な感じはしないと言えるだろう。

ざっとベンチマークを取り直してみて NSD4 が速いことを証明できたので、
今回の目的は達成できたかな。

 

4. 参考文献

Unbound/NSD最新情報(OSC 2013 Tokyo/Spring) http://www.slideshare.net/ttkzw/unboundnsdosc-2013-tokyospring-16708977

NLnetLabs : DNS Response Rate Limiting as implemented in NSD. http://www.nlnetlabs.nl/blog/tag/nsd4/

BIND9 からの卒業 – NSD4 beta4 編

BIND9  の脆弱性の対応に疲れた今日この頃、

(前回のPOSTと以下同文)

この Post では NSD4 beta4 にフォーカスする。

NSD と言えば趣味で DNS をやっているハートビーツ社の滝澤さんが
大変参考になる資料を公開してくれているのでありがたく参考にさせていただきます。
(いつもありがとうございます)

 

0. 検証環境

CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping 07

Memory : DDR3 1333 NonReg ECC 16GB

HDD : 146GB 15000rpm SAS RAID 1

OS : Ubuntu 12.04.2

DNS : NSD4 beta4

 

1. 構築手順(メモ程度)

※大先生にダメ出しされたので configure option などを見直しました。(2013/04/01)
https://twitter.com/ipv6labs/status/318402235610583043

  • 必要なパッケージのインストール

# apt-get install gcc make libssl-dev libevent-dev

  • グループとユーザの追加

# groupadd nsd

# useradd nsd -g nsd

  • ソースを落としてきて make する

# cd /tmp

# wget http://nlnetlabs.nl/downloads/nsd/nsd-4.0.0b4.tar.gz

# tar xf nsd-4.0.0b4.tar.gz

# cd nsd-4.0.0b4/

# ./configure \
–prefix=/usr/local \
–enable-ratelimit \
–with-user=nsd \
–with-libevent \
–with-ssl \
–with-configdir=/etc/nsd4 \
–with-zonesdir=/etc/nsd4/zones \
–with-zonelistfile=/var/cache/nsd4/zone.list \
–with-dbfile=/var/cache/nsd4/zone.db \
–with-xfrdfile=/var/cache/nsd4/xfrd.state \
–with-pidfile=/var/run/nsd4/nsd4.pid \
–with-logfile=/var/log/nsd4.log

# make && make install

  • ちなみに以下のファイルがインストールされるみたいです。

./install-sh -c -d /usr/local/sbin
./install-sh -c -d /etc/nsd4
./install-sh -c -d /var/run/nsd4
./install-sh -c -d /tmp
./install-sh -c -d /var/cache/nsd4
./install-sh -c -d /usr/local/share/man
./install-sh -c -d /usr/local/share/man/man8
./install-sh -c -d /usr/local/share/man/man5
./install-sh -c nsd /usr/local/sbin/nsd
./install-sh -c nsd-control-setup.sh /usr/local/sbin/nsd-control-setup
./install-sh -c nsd-checkconf /usr/local/sbin/nsd-checkconf
./install-sh -c nsd-control /usr/local/sbin/nsd-control
./install-sh -c -m 644 ./nsd.8 /usr/local/share/man/man8
./install-sh -c -m 644 ./nsd-checkconf.8 /usr/local/share/man/man8/nsd-checkconf.8
./install-sh -c -m 644 ./nsd-control.8 /usr/local/share/man/man8/nsd-control.8
./install-sh -c -m 644 ./nsd.conf.5 /usr/local/share/man/man5/nsd.conf.5
./install-sh -c -m 644 nsd.conf.sample /etc/nsd4/nsd.conf.sample

  • 必要なディレクトリを作ってユーザ/グループを変更

# mkdir /etc/nsd4/zones

# chown -R nsd:nsd /etc/nsd4/zones/ /var/cache/nsd4/

  • nsd-control に必要な鍵の生成

# nsd-control-setup

  • コンフィグを書く

# vi /etc/nsd4/nsd.conf

server:
username: nsd
zonesdir: “/etc/nsd4/zones”
zonelistfile: “/var/cache/nsd4/zone.list” # <- これがないと patterns (ゾーンの動的追加・削除)が使用できない
database: “/var/cache/nsd4/zone.db”
logfile: “/var/log/nsd4.log”
pidfile: “/var/run/nsd4/nsd4.pid”
xfrdfile: “/var/cache/nsd4/xfrd.state”

remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: “/etc/nsd4/nsd_server.key”
server-cert-file: “/etc/nsd4/nsd_server.pem”
control-key-file: “/etc/nsd4/nsd_control.key”
control-cert-file: “/etc/nsd4/nsd_control.pem”

# ここから下が NSD4の目玉「patterns」

pattern:
name: “masterzone”
zonefile: “%s.zone”
notify: 10.200.4.226 NOKEY
provide-xfr: 10.200.4.226 NOKEY

pattern:
name: “slavezone”
zonefile: “%s.zone”
allow-notify: 10.200.4.226 NOKEY
request-xfr: AXFR 10.200.4.226 NOKEY

 

2. 既存のゾーンファイルを登録

以下のコマンド1行でゾーンの追加が可能だ。

便利過ぎて吐き気がするぜ。

  • 文法

# nsd-control addzone [DOMAINNAME] [pattern]

  • 実行例

# nsd-control addzone mykw.jp masterzone

ok

# nsd-control addzone wktk.so slavezone
ok

数万ゾーンあるといちいち手打ちするのは骨が折れるのでワンライナー

# for i in `ls -1 | sed ‘s/\(.*\).zone/\1/g’` ; do nsd-control addzone $i masterzone ; done

登録されたか確認

# nsd-control zonestatus
zone: mykw.jp
pattern: masterzone
state: master
zone: wktk.so
pattern: slavezone
state: refreshing
served-serial:  “2013031900 since 2013-04-01T22:48:39”
commit-serial:  “2013031900 since 2013-04-01T22:48:39”

これでお引越しは完了したはずだ。

 

3. 動作確認

適当に dig とかして動作確認をしてみよう。

ちゃんと回答が帰ってくれば動いているはずだ。

# dig @10.200.4.230 mykw.jp soa

ついでに dnsperf でベンチマーク

前回と同じ条件で 32110 行のクエリリストを食わせて 4thread でいじめてみた

  • NSD4 beta4

# dnsperf -c 4 -s 10.200.4.226 -d querylist -l 300
DNS Performance Testing Tool
Nominum Version 2.0.0.0

[Status] Command line: dnsperf -c 4 -s 10.200.4.226 -d querylist -l 300
[Status] Sending queries (to 10.200.4.226)
[Status] Started at: Mon Apr 1 00:41:22 2013
[Status] Stopping after 300.000000 seconds
[Status] Testing complete (time limit)

Statistics:

Queries sent: 44570073
Queries completed: 44570073 (100.00%)
Queries lost: 0 (0.00%)

Response codes: NOERROR 44427108 (99.68%), SERVFAIL 56908 (0.13%), NXDOMAIN 86057 (0.19%)
Average packet size: request 36, response 98
Run time (s): 300.002108
Queries per second: 148565.866077

Average Latency (s): 0.000619 (min 0.000157, max 0.035287)
Latency StdDev (s): 0.000160

 



ちなみにBINDは以下のような結果になった。(前回から流用)
  • BIND 9.8.1-P1

# dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
DNS Performance Testing Tool
Nominum Version 2.0.0.0

[Status] Command line: dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
[Status] Sending queries (to 10.200.4.230)
[Status] Started at: Sun Mar 31 00:28:16 2013
[Status] Stopping after 300.000000 seconds

[Status] Testing complete (time limit)

Statistics:

Queries sent: 58084969
Queries completed: 58084969 (100.00%)
Queries lost: 0 (0.00%)

Response codes: NOERROR 57898647 (99.68%), NXDOMAIN 112154 (0.19%), REFUSED 74168 (0.13%)
Average packet size: request 36, response 225
Run time (s): 300.003788
Queries per second: 193614.118632

Average Latency (s): 0.000313 (min 0.000227, max 0.060098)
Latency StdDev (s): 0.000382

 

4. まとめ

前項の結果でも分かるようにまたもや BIND9 は意外に早かった。

とはいえ、今年も夏のアップデート祭り(略)

クエリを捌く速さが劣っていたとしても NSD4 の素晴らしさは以下の点にあると思っているので
導入するメリットは十分あると思っている。

  • 権威サーバのみのシンプルな構成
  • 脆弱性が発見されることが少ない
  • pattern (macro) によるシンプルな設定ファイル
  • シンプルなオペレーション

シンプルなものほど美しいものはありません。

beta でも十分使えるレベルなので正式版が出るのが楽しみですね。

 

 

 

BIND9 からの卒業 – PowerDNS 3.0 編

BIND9  の脆弱性の対応に疲れた今日この頃、
なぜ BINDを使っているのか自問自答して欝になりかけた日もある(嘘)

そんなこんなで、 BIND9 との決別を決めた。

次の相棒は今 最もホットでナウい PowerDNSNSD4 (beta)
この Post では PowerDNS にフォーカスする。

0. 検証環境

CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping 07

Memory : DDR3 1333 NonReg ECC 16GB

HDD : 146GB 15000rpm SAS RAID 1

OS : Ubuntu 12.04.2

DNS : PowerDNS 3.0

DB : MySQL 5.5.29

 

1. 構築手順(メモ程度) 

  • MySQL と PowerDNS のパッケージインストール

# apt-get install pdns-server pdns-backend-mysql mysql-server mysql-client

  • MySQL にログインしてデータベースとテーブルを作る

# mysql -u root -p

mysql> create database pdns;

Query OK, 1 row affected (0.00 sec)
Create MySQL User

mysql> GRANT ALL ON pdnstest.* TO ‘pdns’@’localhost’ IDENTIFIED BY ‘hogehogepasswd’;

mysql> FLUSH PRIVILEGES;
Change Database

mysql> use pdns;
Database changed
Create Tables

mysql> create table domains (
id INT auto_increment,
name VARCHAR(255) NOT NULL,
master VARCHAR(128) DEFAULT NULL,
last_check INT DEFAULT NULL,
type VARCHAR(6) NOT NULL,
notified_serial INT DEFAULT NULL,
account VARCHAR(40) DEFAULT NULL,
primary key (id)
) Engine=InnoDB;

CREATE UNIQUE INDEX name_index ON domains(name);

CREATE TABLE records (
id INT auto_increment,
domain_id INT DEFAULT NULL,
name VARCHAR(255) DEFAULT NULL,
type VARCHAR(10) DEFAULT NULL,
content VARCHAR(64000) DEFAULT NULL,
ttl INT DEFAULT NULL,
prio INT DEFAULT NULL,
change_date INT DEFAULT NULL,
primary key(id)
) Engine=InnoDB;

CREATE INDEX rec_name_index ON records(name);
CREATE INDEX nametype_index ON records(name,type);
CREATE INDEX domain_id ON records(domain_id);

create table supermasters (
ip VARCHAR(25) NOT NULL,
nameserver VARCHAR(255) NOT NULL,
account VARCHAR(40) DEFAULT NULL
) Engine=InnoDB;

mysql> quit;

  • コンフィグを編集

ここでは Masterでの動作を念頭において設定している。

# vi /etc/powerdns/pdns.conf

allow-axfr-ips=10.200.8.0/24  # <- AXFRできるネットワーク or IPアドレス
config-dir=/etc/powerdns
daemon=yes
default-soa-name=ns0.mykw.jp  # <- SOAレコードに書くDNSのホスト名
disable-axfr=no
disable-tcp=no
local-port=53
log-dns-details=yes
log-failed-updates=yes
logfile=/var/log/pdns.log
logging-facility=0
loglevel=4
master=yes
module-dir=/usr/lib/powerdns
negquery-cache-ttl=60
setgid=pdns
setuid=pdns
use-logfile=yes
version-string=powerdns
include=/etc/powerdns/pdns.d 

DB接続情報は別ファイルに分けて書く

# vi /etc/powerdns/pdns.d/pdns.local.gmysql
# MySQL Configuration
#
# Launch gmysql backend

launch=gmysql
gmysql-socket=/var/run/mysqld/mysqld.sock  # <-ローカルの DB 使うなら Socket 使った方が
gmysql-user=pdns
gmysql-password=hogehogepasswd
gmysql-dbname=pdns

これで一通り使う準備は完了。

 

2. 既存のゾーンファイルを SQL に変換

PowerDNS には zone2sql という便利な SQL 変換スクリプトが標準で用意されている。

BIND で使っていたゾーンファイルを以下の手順で変換・DBへの投入を行う。
素直に変換できないことが多いので、named.conf 調整しながら変換しよう。

  • ゾーンファイルを変換

# zone2sql –gmysql –dnssec=no –named-conf=/etc/bind/named.conf –start-id=1 > zone.sql

  • 変換したレコードをDBにぶち込む

# mysql -updns -phogehogepasswd pdns < zone.sql

  • 変換したゾーンに MASTER のフラグを立てる

これをしないと AUTOSERIAL が有効にならない。

# mysql -u pdns -phogehogepasswd -e “update pdns.domains set type=’MASTER’;”

詳しい説明については公式サイトの Wiki にお任せしよう。

http://wiki.powerdns.com/trac/wiki/Zone2SQLFAQ

 

これでお引越しは完了したはずだ。

 

3. 動作確認

適当に dig とかして動作確認をしてみよう。

ちゃんと回答が帰ってくれば動いているはずだ。

# dig @10.200.4.230 mykw.jp soa

ついでに dnsperf でベンチマーク

32110 行のクエリリストを食わせて 4thread でいじめてみた

  • PowerDNS
# dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
DNS Performance Testing Tool
Nominum Version 2.0.0.0

[Status] Command line: dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
[Status] Sending queries (to 10.200.4.230)
[Status] Started at: Fri Mar 15 18:01:29 2013
[Status] Stopping after 300.000000 seconds
n[Status] Testing complete (time limit)

Statistics:

  Queries sent:         33040355
  Queries completed:    33040355 (100.00%)
  Queries lost:         0 (0.00%)

  Response codes:       NOERROR 32976558 (99.81%), NXDOMAIN 63797 (0.19%)
  Average packet size:  request 36, response 52
  Run time (s):         300.000634
  Queries per second:   110134.283916

  Average Latency (s):  0.000890 (min 0.000144, max 0.431226)
  Latency StdDev (s):   0.001421

ちなみにBINDは以下のような結果になった。

  • BIND 9.8.1-P1

# dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
DNS Performance Testing Tool
Nominum Version 2.0.0.0

[Status] Command line: dnsperf -c 4 -s 10.200.4.230 -d querylist -l 300
[Status] Sending queries (to 10.200.4.230)
[Status] Started at: Sun Mar 31 00:28:16 2013
[Status] Stopping after 300.000000 seconds

[Status] Testing complete (time limit)

Statistics:

Queries sent: 58084969
Queries completed: 58084969 (100.00%)
Queries lost: 0 (0.00%)

Response codes: NOERROR 57898647 (99.68%), NXDOMAIN 112154 (0.19%), REFUSED 74168 (0.13%)
Average packet size: request 36, response 225
Run time (s): 300.003788
Queries per second: 193614.118632

Average Latency (s): 0.000313 (min 0.000227, max 0.060098)
Latency StdDev (s): 0.000382

 

 

4. まとめ

前項の結果でも分かるように BIND9 は意外に早かった。

とはいえ、今年も夏のアップデート祭り(予定)に参戦するのはイヤということで
しばらく自宅環境はPowerDNSで頑張ってみることにした。

ちなみに今回使ったマシンの前にはRAIDキャッシュなしのマシンで検証していたのだが、
スコアは半分ぐらいであまりふるわない成績だった。
SQL を使っているので Disk I/O に引っ張られる印象があるが、
update が多いようなアプリケーションではないので DISKが遅いマシンでも
querycache をたんまり盛ってあげればそこそこ捌いてくれそうな気がする。

SSDとかNANDフラッシュ系の高級ストレージって楽するという選択もありですかね。
空から iodrive か intel SSD 910 降ってこないかな。

Ubuntu 12.04 Desktop でEMOBILE GL04PをUSB接続してみた

昨今、S●ftbankやKD●Iなどの携帯電話キャリアがWifiのアクセスポイントをバラまいて、
有線回線へのオフロードを謀っておりますが、その影響でWifiのチャンネルが埋まってしまい、
いざというときにPocketWifiが使えないといったことが多くなってきた気がします。

※そもそもモバイルルータを持ち歩く人が多くなったせいもあるか。

WindowsもMacも使っていない私はUSBのドライバが用意されていないと思い込みで
数か月間EMOBILE GL04Pを使って来ましたが、勉強会・セミナーで不便を強いられることが
多くなってきたので、仕事をサボ(ry 快適環境を追い求めてみました。

手順は以下の通り。

1.ドライバのダウンロード

これが一番探すのに苦労した。

HUAWEIのサイトからLinux用ドライバを入手

http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=software&softid=NDcwMzU=

 

2.ドライバの展開

なぜかZIPを展開するとtar.gzが出てくるのでさらに展開

$ unzip HUAWEI\ Data\ Cards\ Linux\ Driver.zip

$ tar xf Linux\ Driver\ 4.19.19.00.tar.gz

 

3.ドライバのインストール

インストーラがついているので、実行するとmakeが始まる

$ cd driver/

$ sudo ./install

4.再起動

再起動してGL04Pを接続するとNetworkManagerで認識しているはずだ。

あまりに簡単すぎてあれだが、ドライバを探すのに時間を費やしたので記録に残しておく。

Ubuntu12.04 DesktopでSynergyを自動起動で使いたい(メモ)

Linux版Synergyの導入手順メモ(For Ubuntu12.04)

http://sourceforge.net/projects/synergy2/

1. synergyをインストール

# apt-get install synergy

2. configを作る(ml115:server op740:client)

# vi /etc/synergy.conf
section: screens
ml115:
op740:
end

section: links
ml115:
left = op740
op740:
right = ml115
end

3. lightdm起動時に一緒に起動させる

# vi /etc/lightdm/lightdm.conf

[SeatDefaults]
user-session=ubuntu
greeter-session=unity-greeter
#greeter-setup-script=/usr/bin/synergyc 192.168.2.80 ←クライアントとして使うとき(サーバのIP)
greeter-setup-script=/usr/bin/synergys -c /etc/synergy.conf  ←サーバとして使うとき

 

[email protected]でCUDAをつかってみる (Ubuntu 12.04) その1

最近、某所の余ったりソースで[email protected]に参加しています。(アカウントは昔から持っているのですが)

某チームのランキングも日に日にあがっていくので欲が出てきてもっと上位に食い込みたいなということで、
これまたあまったGPU(GeForce210という非力なビデオカード)でCUDAを使ってみました。
CUDAについては詳細を割愛します。

今回はとりあえずUbuntu12.04でのCUDA環境の構築手順をメモ程度に。
以下の作業はrootかつデスクトップサービスを落とすのでSSH(CLI)での作業を想定しています。

デスクトップサービスを落とす

# service lightdm stop

オープンソース版のビデオカードドライバをアンインストールして再起動

# apt-get purge nvidia*
# reboot

再起動したらnVidiaのUbuntu用のドライバをダウンロードする。
以下のサイトから自分のモデルにあったものを探す。

http://www.nvidia.com/object/unix.html

# wget http://us.download.nvidia.com/XFree86/Linux-x86_64/310.19/NVIDIA-Linux-x86_64-310.19.run

落としてきたドライバに実行権を与えて実行、終わったら再起動

# chmod +x NVIDIA-Linux-x86_64-310.19.run
# ./NVIDIA-Linux-x86_64-310.19.run
# reboot

 

CUDA5をインストール
下記サイトからインストーラをダウンロード
https://developer.nvidia.com/cuda-downloads

# wget http://developer.download.nvidia.com/compute/cuda/5_0/rel-update-1/installers/cuda_5.0.35_linux_64_ubuntu11.10-1.run

実行権を与えて実行する

# chmod +x cuda_5.0.35_linux_64_ubuntu11.10-1.run
# ./cuda_5.0.35_linux_64_ubuntu11.10-1.run

いろいろ聞かれるがToolkitとTemplateはいらないのでインストールしなくてもいいらしい。

Screenshot_from_2012-12-12 22:43:44

これでGPGPUが使えるはず。

効果についてはその2を書く予定です。

 

 

X86Android 4.0 RC2 on KVM

表題のとおり、X86Android 4.0 RC2をLinuxKVMで動かしてみました。
NICまわりで手こずったのでメモメモ。

下記のサイトを参考に、Ethernet patchのあたったイメージを使用する前提で話を進めます。

http://www.webupd8.org/2012/07/android-x86-404-ics-rc2-released-with.html

イメージは以下のものを使用しました。(なかなかダウンロードできない)

http://www.sendspace.com/file/t5a3aj

ISOを用意して、virtinstallで普通にインストールします。
ポイントはNICをmodel=e1000にするところですかね。これでインテルNICをエミュレートしてくれます。

$ sudo virt-install \
–connect=qemu:///system \
–name android4.0 \
–ram 512 \
–disk path=/var/lib/libvirt/images/android4.0.img,cache=writeback,sparse=true,size=5 \
–cdrom=’/home/yutaro/iso/desktop_generic.iso’ \
–vcpus=1 \
–os-type linux \
–os-variant generic26 \
–network bridge=br0,model=e1000 \
–vnc \
–accelerate \
–hvm

インストールが終わったら、デフォルトで入っている「端末エミュレータ」で /etc/init.sh を編集して
起動時にIPアドレスをStaticで振るようにする。(GUIの設定画面は使えませんでした)
各種アドレスは自分の環境に合わせて設定してください。

$ su –

# vi /etc/init.sh
(略)
ifconfig eth0 [IP ADDRESS] up ;Androidゲストのeth0にIPをつける
route add default gw [GATEWAY ADDRESS] dev eth0 ;デフォゲを指定する
setprop net.dns1 [RESOLVER ADDRESS] ;リゾルバ(DNSキャッシュサーバ)を指定する

これで再起動するとネットワークにつながっているはず。
pingとかで確認してみましょう。

仕事中に眠くなってきたので
といった感じで遊んでみました。

 

ユーザ権限で virt-manager がが

デスクトップOSとしてUbuntuを使うとサーバとの連携がいろいろと楽でいいのですが、
まれにその連携がうまくいかないことがあります。

今回はユーザ権限で起動したvirt-managerでlibvirtdに接続ができなかったので
対応した内容をメモ書きで残しておきます。

0. 環境

OS:Ubuntu 12.10 Desktop

1. エラー内容

libvirt に接続できませんでした。

Verify that:
– The ‘libvirt-bin’ package is installed
– The ‘libvirtd’ daemon has been started
– You are member of the ‘libvirtd’ group

Libvirt URI is: qemu:///system

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 1027, in _open_thread
self.vmm = self._try_open()
File “/usr/share/virt-manager/virtManager/connection.py”, line 1009, in _try_open
flags)
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 102, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: ソケットの ‘/var/run/libvirt/libvirt-sock’ への接続に失敗しました: 許可がありません

 

2. 対応内容

[email protected]:~# vi /etc/libvirt/libvirtd.conf

[email protected]:/etc/libvirt# diff libvirt.conf.def libvirtd.conf
88c88
< unix_sock_ro_perms = “0770”

> unix_sock_ro_perms = “0777”
98c98
< unix_sock_rw_perms = “0770”

> unix_sock_rw_perms = “0777”
101c101
< #unix_sock_dir = “/var/run/libvirt”

> unix_sock_dir = “/var/run/libvirt”

[email protected]:~# service libvirt-bin stop
libvirt-bin stop/waiting
[email protected]:~#
[email protected]:~# service libvirt-bin start
libvirt-bin start/running, process 4368
[email protected]:~#

 

デフォルトではソケットファイルが作られないので、
ソケットファイルを生成しつつotherに権限を与えてあげれば良いかと。

ただ、otherに権限与えるのがあまり好ましくない環境ではおすすめしません。
よくよく考えるとlibvirtdグループに実行ユーザ加えてあげればいいような・・・

Ubuntu 12.04 LTS で zfs その2

前回のzfs環境構築に続いてzpoolへのディスクの追加について
いくつか注意点があったのでまとめてみた。

以下のコマンドで基本的な操作が行える。

  • ディスク構成の確認

# zpool status

  • プールの作成# zpool create  [zpool name] [device name]
  • ディスクの追加

# zpool add  [zpool name] [device name]

  • プールの削除

# zpool destroy  [zpool name] [device name]

とてもシンプルで分かりやすい。
洗練されていますね。

ということで、自分のMicroServerにもディスクを追加してみた。

[email protected]:/# zpool create  storage0 sda sdb

あっけなく終了。簡単過ぎる。
だが、ここに罠があった。

今回zpoolに追加したHDDはWesternDigital製のWD30EZRX(3TB)でした。
最近のHDDは大容量化のオフセットとして1ブロックあたりのサイズを大きくしているので、
それに合わせてフォーマットしてあげないと著しくパフォーマンスが落ちます。

AFT(Advanced Format Technology) ってやつですね。

なので、AFTなディスクをzpoolする際には以下のような引数を加えてあげるとフワフワっと
ブロックの開始位置とブロックサイズをしてくれます。

  • プールの作成(AFTなディスクの時)

[email protected]:/# zpool create -o ashift=12 storage0 sda sdb

引数の有無でどれだけパフォーマンスの差が出るのか、試しに dd コマンドでベンチマークしてみました。

  • 引数なし(ブロックサイズ512Byte)
[email protected]:~# zdb -C storage0 | grep ashift
                ashift: 9
                ashift: 9 ※ ashift: 9はブロックサイズ512Byte
[email protected]:~#
[email protected]:~# dd if=/dev/zero of=hogehoge bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 220.772 s, 47.5 MB/s
  • 引数あり
[email protected]:~# zdb -C storage0 | grep ashift
                ashift: 12
                ashift: 12 ※ ashift: 12はブロックサイズ4KByte
[email protected]:~# dd if=/dev/zero of=hogehoge bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 61.0622 s, 172 MB/s
開始位置とブロックサイズ適切にするだけで3倍速くなりました。
せっかく良いハードウェアを買ってもソフトウェア側の処理で最大限のパフォーマンスを
発揮できないと言う可哀想な自体は避けたいですね。