ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2022年3月28日月曜日

シェルスクリプトで unixtime を扱う

シェルスクリプト内で unixtime を得るには /bin/date +%s が利用できます。この方法で取得した unixtime はシェルスクリプト内で加算・減算したり、比較したりできます。

以下は、 sleep に頼らずに $TIMEOUT 秒間待機する例です。単純に sleep $TIMEOUT と記述するよりも、柔軟な待機ループを実装できます。

TIMEOUT=10
TIME_START=`/bin/date +%s`             # ループ開始時刻(いま)
TIME_END=$((${TIME_START} + ${TIMEOUT})) # ループ脱出時刻

echo -n running
while [ `/bin/date +%s` -lt ${TIME_END} ]; do
        sleep 1
        echo -n .
        
        # MySQL Server への接続性が確認できたら $TIMEOUT 秒待たずにループを抜ける 
        mysql -e 'SHOW STATUS' 1> /dev/null 2> /dev/null && break
done

2022年3月25日金曜日

Linux KVM + virtio-net のレイテンシーを削減するヘンな方法

Linux KVM の virtio-net を利用している際にリモートホストへの PING 結果がマイクロ秒のオーダーで安定しない(ブレる)という話を見かけました。

Linux KVM の仕組みや QEMU のデバイスエミュレーションの仕組みを考えれば「そんなもの」かなと思い、調査および追加の実験をしてみました。なお、本記事は x86 アーキテクチャの Linux KVM の動作に基づきます。


パケットが送信される仕組み

ping コマンドなどにより発生した、送信パケットは OS のネットワークスタック(L3, L2)を通じてイーサネットのドライバに引き渡されます。
今回はLinux KVMのデバイスエミュレーションを利用した際のレイテンシーに注目したいため、プロセスからデバイスドライバまでデータ届く流れについては触れません。 Linux KVM の仮想マシンで使われる virtio-net に注目します。
仮想的なネットワークインターフェイスである virtio-net 、またそのベースとなる、ホスト−ゲスト間の通信に使われる virtio-pci では、ゲストOSのメモリ空間にある送信対象データをバッファへのポインタをリングバッファに積み、I/Oポートを叩くことで VMM (Linux KVM) 側に通知します。
このあたりの仕組み(PCIデバイスに模倣する virtio のゲスト・ホスト間通信の仕組み)は過去にエンジニアなら知っておきたい仮想マシンのしくみ スライドにて解説しているので、そちらもご確認ください。

https://github.com/torvalds/linux/blob/4f50ef152ec652cf1f1d3031019828b170406ebf/drivers/net/virtio_net.c#L1762 に、ホストへ通知すべき送信データが準備できた際ホスト側の virtio-net に通知するブロックがあります。
        if (kick || netif_xmit_stopped(txq)) {
            if (virtqueue_kick_prepare(sq->vq) && virtqueue_notify(sq->vq)) {
			u64_stats_update_begin(&sq->stats.syncp);
			sq->stats.kicks++;
			u64_stats_update_end(&sq->stats.syncp);
		}
	}

virtqueue_notify(sq->vq) は仮想デバイスの I/O ポートへのアクセスする実装となっています。そのセンシティブ命令を契機としてゲストから VMM に制御が移ります。デバイスモデル(qemu-kvm)のI/Oポートハンドラがゲストからの割り込み理由を判断し、 virtio-net のゲスト側リングバッファにあるデータをバックエンドのネットワークインターフェイスに渡します。
この際(Intel 表記で) VMX non-root → VMX root の kvm → qemu-kvm (ring3) と遷移し、場合によっては qemu-kvm がネットワークスタックにパケットを渡す前にプリエンプションが発生する可能性があり、送信タイミングが遅れる原因になり得ます。

 パケットが受信される仕組み


では、パケットが届いた場合はどうなるでしょうか? qemu-kvm がゲスト行きの受信データを受け取ると、予め用意されているゲスト側のメモリ領域に受信データを書き込み「ゲストに対して割り込みをかけます」。
本物のx86のプロセッサであれば、IRQ(Interrupt ReQuest)を受け付けるための信号線があり、それを介して割り込みを通知する方法と、割り込み通知用のアドレス空間に対するメモリ書き込みトランザクションにより割り込みを通知するMSI(MSI-X)割り込みがあります。仮想マシンの場合、仮想プロセッサにはIRQ線、MSI通知用のアドレス空間にメモリトランザクションを行ってもそれを受けてくれる相手がいないので、仮想マシンのプロセッサを「割り込みがかかった状態」にすることで割り込む挿入を実現することになります。

https://github.com/torvalds/linux/blob/0564eeb71bbb0e1a566fb701f90155bef9e7a224/arch/x86/kvm/vmx/vmx.c#L4574 にある vmx_inject_irq() に、 Intel VT でゲストに割り込みを通知する実装があります。
static void vmx_inject_irq(struct kvm_vcpu *vcpu)
{
	struct vcpu_vmx *vmx = to_vmx(vcpu);
	uint32_t intr;
	int irq = vcpu->arch.interrupt.nr;

	trace_kvm_inj_virq(irq);

	++vcpu->stat.irq_injections;
	if (vmx->rmode.vm86_active) {
		int inc_eip = 0;
		if (vcpu->arch.interrupt.soft)
			inc_eip = vcpu->arch.event_exit_inst_len;
		kvm_inject_realmode_interrupt(vcpu, irq, inc_eip);
		return;
	}
	intr = irq | INTR_INFO_VALID_MASK;
	if (vcpu->arch.interrupt.soft) {
		intr |= INTR_TYPE_SOFT_INTR;
		vmcs_write32(VM_ENTRY_INSTRUCTION_LEN,
			     vmx->vcpu.arch.event_exit_inst_len);
	} else
		intr |= INTR_TYPE_EXT_INTR;
	vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr);

	vmx_clear_hlt(vcpu);
}
ここでのキモは intr |= INTR_TYPE_EXT_INTR もしくは INTR_TYPE_SOFT_INTR です。 Intel VT では、仮想プロセッサの状態を管理するVMCS構造体に対して特定のビットを立てておくと、「次にその仮想マシンを実行するときに、ゲスト側で割り込みハンドラに処理が移される」仕組みです。ただし、ここでは実際に仮想マシンの実行し、割り込みハンドラに処理を移してはいないことに注意が必要です。

では、具体的にいつ、仮想マシンの割り込みハンドラが実行されるのでしょうか?答えは、Linux KVM + qemu-kvm の場合 qemu-kvm のメインループでCPUスレッドが改めて VMX non-root モードに移行するように要求したときです。

「次に仮想CPUを実行するときは割り込みハンドラを実行する必要があるよ」設定されても、その次にスケジュールされるタイミングは qemu-kvm の仮想CPU実行スケジュール、Linuxのスケジューラに依存することになります。仮想マシンのCPU負荷が低い場合には、qemu-kvmはVMX non-rootへの遷移を抑制して他のプロセスへのプリエンプションを許すことにより負荷を下げます。しかし、パケットが届いた後にqemu-kvmのCPUスレッドにプリエンプションが発生し、VMX non-rootへ遷移するまでがネットワークレイテンシーの増加として見えることになります。


VMX non-root でのビジーループは解決策になるか

では、ゲストがビジー状態でCPUを使い続ければ他のプロセスへのプリエンプションが発生せず、レイテンシーに改善が見られるのではないか?という仮説がありました。この方法で、ゲストOSがHLT命令などを発効してCPUを手放すことが減るというメリットは確かにありそうですが、2つの考慮点があります。
  • 仮想プロセッサが割り込みハンドラに制御を移すのはVMX rootからVMX non-rootに制御を移すタイミングです。このため、VMX non-rootでビジーループを回っていても割り込みハンドラに制御が移るわけではありません。
  • VMX non-rootでビジーループを回り続けた果てにVMX rootに遷移したとき、Linux カーネルから見れば、そのCPUスレッドは「大量のCPU時間を消費した」プロセスと認識します。このため、負荷が高いシステムでは、Linuxカーネルは他のプロセスに積極的にプリエンプションしようとするでしょう。これでは、次回のVMX non-rootへの遷移が遅れてしまいます。


ちょっとしたカーネルモジュールでレイテンシー性能を改善する

ここでは、ちょっとしたカーネルモジュールをロードして、レイテンシー改善が可能かを試してみました。コードは https://github.com/hasegaw/cheetah/blob/master/cheetah.c です。以下の関数をカーネルスレッドとしてビジーループで回します。

static void kthread_main(void)
{
        u32 vmx_msr_low, vmx_msr_high;

        rdmsr(MSR_IA32_UCODE_REV, vmx_msr_low, vmx_msr_high);

        schedule();
}

rdmsr は、 x86 アーキテクチャにある Machine-Specific Register を読み取ります。この命令はデバイスモデルでのエミュレーションが必要になるセンシティブ命令であるため、強制的に VMEXIT が発生して VMX non-root → VMX root への遷移が発生し、qemu-kvmでRDMSRのエミュレーションが行われ、その結果をもって再度VMENTERされます。
RDMSRのエミュレーションは未改造のqemu-kvmにおいて比較的コストの低いエミュレーション処理で、特に副作用が想定されないため、これを選んでいます。HLTなどを利用するとVMMがすぐにゲストに処理を戻さないかもしれませんが、RDMSRであれば、他プロセスへのプリエンプションがない限りは、すぐに再度VMENTERによりVMX non-rootに移行することが想定され、このタイミングで割り込みハンドラへの制御が移るわけです。


測定結果

Linux KVMで動作するシステム上のLinuxゲスト間でpingコマンドを実行した際のレイテンシーを測定してみました。下記が90%パーセンタイル値です。
  • RDMSRのビジーループなし(通常の状態) —— 614us (100.0%)
  • RDMSRのビジーループなし、ゲスト内で perl -e 'while(1) {}' でビジーループ —— 516us (84.0%)
  • RDMSRのビジーループあり —— 482us (78.5%)
ごく一般的なLinuxゲストと比較すると、先のRDMSRのビジーループを回したLinuxゲストでは20%程度のレイテンシー低下が確認できました。

このデータは2021年3月(本記事の執筆時点からちょうど1年前)に割とノリで試したもので、であまり細かいデータを取っていないため、上記の値しか残っていないことにはご容赦ください。


割り込み通知からポーリングループへの移行

ゲストがビジー状態で回り続けていても通知を受けられないのなら、ひとつの選択肢としてはポーリングループでホストからの通知が受けられたらいいのに、という発想になるかと思います。実際、DPDKではプロセスがループでポーリングし続けることで大幅にレイテンシーを短縮しているわけです。ホストOSからゲストOSへの通知をポーリングループで監視すればよいのではないでしょうか?

今回は、virtio-netに対して手を入れるような事はしなかったのですが、ホストOSからの割り込み通知を待たずにリングバッファへ新着データを拾いにいくことは可能な気がします。しかし、本当にレイテンシー面を気にするのでれば SRIOV などを検討するほうがいいでしょう。

Linux KVM ではありませんが、同じく Intel VT ベースで仮想マシン技術を提供する VMware 社のホワイトペーパー Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs には、下記の記述があります。



まとめ

Linux KVM の virtio-net を利用している際にリモートホストへの PING 結果がマイクロ秒のオーダーで安定しない(ブレる)理由について、Linux KVM、qemu-kvmとゲスト側カーネルの間で何がおきるかを考えてみました。
また、ゲストへの割り込み挿入タイミングを増やすために、ゲストカーネル上で数行で書けるカーネルスレッドを動かすことにとって、実際にレイテンシー性能がいくらか向上することを確認しました。
マイクロ秒オーダーの時間のブレを気にする場合は、最終的にはSRIOVやポーリングモードの導入、そもそも(VMENTER/VMEXITだって遅いので)VMM上ではなく物理的なマシンの利用が解決策になると思いますが、仮想マシンのしくみがこんな物なんだと理解しておくのは悪くない事かと思います。




2022年3月24日木曜日

シェルスクリプトで MySQL サーバーが起動してくるのを待つ

 10年ほど前にメッチャ MySQL で TPC-C を回していたときに使っていた方法です。

echo -n "Waiting for the database ready...."
while true; do
        sleep 1
        mysql -h ${TPCC_HOST} -P ${TPCC_PORT} -u ${TPCC_USER} --password=${TPCC_PASSWORD} \
                -e 'show status' 1> /dev/null 2> /dev/null  &&  break
        echo -n '.'
done
echo 'up'

MySQLクライアントでサーバに接続し適当なクエリを実行できるかでアクセス性があるか判断しています。このクエリが実行できるようになるまでここでブロックし、問題なくクエリが実行できれば終了コードとして 0 が返されますので && break が実行されループを抜けます。

今回はサーバがクエリを受け付けられるようになるまで待っていますが、同じ方法を用いて、クエリが実行できるかどうかで処理内容を条件分けすることもできますね。

mysql -h ${TPCC_HOST} -P ${TPCC_PORT} -u ${TPCC_USER} --password=${TPCC_PASSWORD} \
        -e 'show status' 1> /dev/null 2> /dev/null
# 上記 mysql コマンドの終了コードが格納された $? を見て処理を分岐する
if [ $? -eq 0 ]; then
    echo "クエリが成功した"
else
    echo "サーバに接続できなかった、クエリが失敗した"
    exit 1 # ゼロ以外の値でシェルスクリプトを異常終了させる
fi

exit 0 # 正常終了

2018年12月4日火曜日

AMD GPUによるディープラーニング環境の構築

こんにちわ。さくらインターネット 高火力コンピューティングの雑用担当 @hasegaw です。このエントリはさくらインターネット Advent Calendar 2018 4日目のエントリです。なお、前日のエントリは UIT#5 で登壇してきました + 資料への補足 でした。


新しい Radeon GPU が登場

1ヶ月ほど前になりますが、2018年11月6日に、AMDが新しいGPU 「Radeon Instict MI60」を発表しました。4096のストリームプロセッサー、1TB/sの高帯域幅な32GB HBM2メモリを搭載し、PCIe 4.0 16レーンに対応したGPUです。また、ストリームプロセッサーが 3840 に変更された Radeon Instict MI50 というモデルを紹介されています。

AMDが7nm提供開始、Vega「Radeon Instinct MI60」と最大64コアのRomeこと新「EPYC」を発表
http://ascii.jp/elem/000/001/768/1768981/


ディープラーニングと Radeon GPU

Radeon GPUといえば、2018年はマイニングで話題になったりもしましたが、OpenCLによる計算用途にも利用できます。また、最近では ROCm と呼ばれるソフトウェア群によってディープラーニング目的でも使えるようになりました。

本当に動くの?

Radeon でディープラーニングってきちんと動くの?ちょっと試してみないと判らないな……と思われたりするでしょうか?

私は、高火力コンピューティングの仕事をしつつ、サイドプロジェクトで GPU を使ったりもするので、そのときはデータセンターをおいたマシンを使ったりもするのですが、かといって高価な Tesla を常に浪費するのも心が痛むので、最近は 10分の1のコストで済む Radeon で事足りる作業なら Radeon GPU を使ってみています。にわか機械学習マンとしては、現状 Radeon GPU で困ったことはありません。

最近は TensorFlow もアップストリームに追従するかたちで ROCm 対応版が作られており、動かしてみても、だいたいの場合は問題なく動くようです。また、 Radeon Instict シリーズに一気にいかなくとも、秋葉原で手に入る Radeon シリーズでとりあえずの味見をすることも可能です。

「本当に自分が持っているワークロードが動くの?」と気になる方は、 Pegara 社の GPU EATER をお試しになられてはいかがでしょうか。

GPU EATER
https://www.gpueater.com/

なんと1時間あたり1ドル未満で、RadeonシリーズのGPUサーバーを試せます。また、ログインは事前に用意したSSH公開鍵に対応する秘密鍵でSSHするだけ。利用開始も簡単で、最初から ROCm フレームワークや TensorFlow サンプルなども入っています。

root@C-2b457c0e-0884-4f80-94fc-4bbeec7ecb4c-685:~/deep_learning_yolo_v3# python3 yolo.py  image.jpg
Using TensorFlow backend.
2018-10-10 04:56:03.761749: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1519] Found device 0 with properties:
name: Device 687f
AMDGPU ISA: gfx900
memoryClockRate (GHz) 1.622
pciBusID 0000:03:00.0
Total memory: 7.98GiB
Free memory: 7.73GiB
2018-10-10 04:56:03.761786: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1630] Adding visible gpu devices: 0
2018-10-10 04:56:03.761820: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1039] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-10-10 04:56:03.761829: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1045]      0
2018-10-10 04:56:03.761848: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1058] 0:   N
2018-10-10 04:56:03.761907: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1178] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7524 MB memory) -> physical GPU (device: 0, name: Device 687f, pci bus id: 0000:03:00.0)
model_data/yolo.h5 model, anchors, and classes loaded.
(416, 416, 3)
Found 5 boxes for img
person 0.94 (143, 281) (216, 495)
person 0.97 (112, 17) (207, 331)
person 0.99 (239, 297) (317, 514)
person 0.99 (253, 98) (319, 364)
person 1.00 (38, 165) (102, 436)
20.274007220985368
Output => image.jpg.out.jpg


ROCm 環境のインストールって難しくないの? → 思ったより簡単でした

手元に実際の Radeon GPU を用意し、環境を構築するにはどれぐらいの苦労があるでしょうか?実際  Ubuntu 16.04 ベースで試してみたときは、思ったほど難しくはありませんでした。 https://github.com/hasegaw/rocm-tensorflow-ansible/ に、私が環境作成に使用している Ansible role から抜粋したものをおいておきますので、必要に応じて加工して利用してください。何をしているかというと

ROCM 環境の構築)

  • カーネルの更新
  • apt に ROCm レポジトリを追加
  • ROCm 関連パッケージをインストール。カーネルモジュールは DKMS で設定されます
  • /etc/profile.d/ に設定ファイルを展開
  • 必要に応じてユーザ(既存/今後の作成時のデフォルト)のグループ設定を変更
TensorFlow のインストール)
  • virtualenv をインストール
  • virtualenv 上に tensorflow-rocm をインストール
といった感じです。 ROCm は repo.radeon.com からのパッケージを拾えば動きますし、 TensorFlow も AMD 社がポートしたバージョンを PyPI に適宜パブリッシュしてくれているので、 pip install するだけの時代が来ているのです。


利用感はどう?

どちらかといえば、パフォーマンスの面よりも、秋葉原などの店頭でカジュアルに手に入る Radeon Vega 64 は 8GB メモリモデルぐらいしか市場で見かけておらず、 Radeon Vega Frontier Edition (12GB) がほぼ市場から消えている状況で利用できるメモリ量が少ない点が、がつがつワークロードを回そうと思うと、ちょっと気になるかもしれません。

ワークロードによるので一概に言えないのですが、私が試した範囲では Radeon Vega 64 で NVIDIA TITAN X の8割から同等程度のパフォーマンスが得られていました。 GDDR5 搭載の NVIDIA GPU が HBM 搭載の Radeon Vega 64 に対して優位なのは NVIDIA すごいなーと思いますし、 Radeon 上でのチューニングはこれからなのかな、という感じがします。

現状の tensorflow-rocm は、CUDAバージョンのカーネルをコンバートして使っているようなので、このあたりの最適化が進めばさらに性能が伸びる余地もありそうです。例えば  GitHub 上のアクティビティを眺めていると、和算+活性の "Fusion" カーネルの実装なども最近行われていました。どんどんアップデートされているので、今後が楽しみです。


まとめ

AMD Radeon シリーズでのディープラーニングもそろそろ実用段階に入ってきたのではないか、という感じがしています。

ただ、ディープラーニング用途で Radeon 系 GPU をすでに持っている方はほとんどいないでしょう。そんな時でも、ご紹介したとおり、 Pegara 社が非常にお安い価格で Radeon GPU を利用できる GPU EATER を提供されていますので、興味が湧いたら、こちらのサービスを試してみてはいかがでしょうか。

2017年2月8日水曜日

ブートイメージからカーネル、rootfs、configを取り出す

image.ub ファイルからカーネル、rootfs、/proc/configを取り出す

SDSoC 2016.3に含まれる ZYBO 向け Software Platform からカーネル、 rootfs、/proc/config を取り出したかったので取り出した。

そもそも image.ub ってなんだ


ARMで使えるブートローダu-bootが扱うイメージフォーマットらしい。

$ mkimage -l image.ub
FIT description: PetaLinux arm uImage with single Linux kernel and FDT blob
Created:         Fri Nov 18 04:07:34 2016
 Image 0 (kernel@1)
  Description:  PetaLinux Kernel
  Created:      Fri Nov 18 04:07:34 2016
  Type:         Kernel Image
  Compression:  gzip compressed
  Data Size:    8747883 Bytes = 8542.85 kB = 8.34 MB
  Architecture: ARM
  OS:           Linux
  Load Address: 0x00008000
  Entry Point:  0x00008000
  Hash algo:    crc32
  Hash value:   252654ca
 Image 1 (fdt@1)
  Description:  Flattened Device Tree blob
  Created:      Fri Nov 18 04:07:34 2016
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    13962 Bytes = 13.63 kB = 0.01 MB
  Architecture: ARM
  Hash algo:    crc32
  Hash value:   66629950
 Default Configuration: 'conf@1'
 Configuration 0 (conf@1)
  Description:  PetaLinux Boot Linux kernel with FDT blob
  Kernel:       kernel@1
  FDT:          fdt@1


カーネルを取り出す


まずこのイメージからカーネルを取り出す。 mkimage -l の結果から gzip compressed であることがわかっているので、 magic を頼りに探すと 240バイト目から gzip データがあることがわかる。 mkimage の結果からファイルは 8747883 バイトであることがわかる。

$ grep -P -a -b  --only-matching $'\x1F\x8B\x08' image.ub
240:

なので

$ dd if=image.ub of=linux.bin.gz bs=1 skip=240 count=8747883
8747883+0 records in
8747883+0 records out
8747883 bytes (8.7 MB, 8.3 MiB) copied, 6.91697 s, 1.3 MB/s

$ file linux.bin.gz
linux.bin.gz: gzip compressed data, was "linux.bin",
  last modified: Thu Nov 17 19:07:33 2016, max compression, from Unix


カーネルの中から gzip データを取り出す


さらにこのアーカイブの中にrootfsが含まれている。cpioフォーマットで入っているかと思い、cpioフォーマットのヘッダである"070707"をgrepしたら発見... と思ったがハズレだった。これはcpioアーカイブじゃなくてcpioアーカイブを探すプログラムが参照している文字列っぽい。ということは...

$ grep -P -a -b  --only-matching $'\x1F\x8B\x08' linux.bin
6278680:
8588960:
9923536:

gzip のヘッダらしきものが3つ見つかった。まずひとつ目は...

$ dd if=linux.bin skip=6278680 bs=1 | gzip -dc > hoge

gzip: stdin: decompression OK, trailing garbage ignored

toor@gpusv:~/zynq7/extract_initramfs$ file hoge
hoge: Linux make config build file, ASCII text

ASCIIだと!?

$ head hoge
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.6.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y

...config.gz だった。まあ、ついでなので保存。

$ mv hoge config


では次。

$ dd if=linux.bin skip=8588960 bs=1 | gzip -dc > hoge
gzip: stdin: decompression OK, trailing garbage ignored

toor@gpusv:~/zynq7/extract_initramfs$ file hoge
hoge: ASCII cpio archive (SVR4 with no CRC)

toor@gpusv:~/zynq7/extract_initramfs$ cat hoge | cpio -it | head
cpio: Substituting `.' for empty member name
.
dev
dev/pts
etc
etc/opkg
etc/opkg/arch
etc/rpm
etc/rpm/sysinfo
etc/rpm-postinsts
etc/network

今回は間違いなくinitrdイメージだ。

$ mv hoge initrd


目的な達成したけど、3つめはなんじゃらほい。
dd if=linux.bin skip=9923536 bs=1 | gzip -dc > hoge
gzip: stdin has flags 0xce -- not supported


これは有効なgzipじゃなかった。"070707" 同様に gzip をデコードするルーチンが参照している定数かも。

2016年10月16日日曜日

PYNQを買ったので遊んでいる(Project Inq)

久々にFPGAいじりをしています。

今回入手してしまったのはPYNQ。Xilinx Zynq7020シリーズを搭載した評価ボードで、あらかじめ用意されたイメージをSDカードに書き込んであげればJupiterからWebブラウザ経由でもいくらか操作を試せるというお手軽さがウリ。



届いたPYNQのパッケージ

秋葉原の職場に送ってもらったので、受け取ったら早々と部品やでヒートシンクと熱伝導シーツを調達。

SDカードにイメージを焼いて起動したら、当然とはいえ、普通にヘッドレスなARM7 Linuxマシンとして起動してきた。OSはUbuntu 15。 OpenCVは 3.1 で、FFmpegサポートも入った状態でコンパイルされている。……これは色々と便利なのでは?

試しにIkaLogでビデオファイルを解析させてみたら、あっけないほど簡単に動いた。

PYNQにはビデオキャプチャ利用を想定したHDMI Inputポートがあるので、これでキャプチャできるかは大変興味があるところ。Jupiter上でOpenCVの顔認識をするコードを途中まで実行したら、WiiUの画像がキャプチャできた。



ただしPYNQのbase.bitではDDCの応答内容に問題があるのかWiiUからビデオ信号が出てこない。このためHDMIマトリックススイッチやスイッチャーなどの機械を挟んでいる。また、720pだと色々安定していないような感じ……。過去に試していたとき、ZYBOではDigilentのdvi2rgbのEDIDを書き換えたらWiiUの信号を直接、安定して食えるようになったので、そのときの成果を持ってくれば解決するだろう。だいたい解決策は見えているので後回し。ちなみに以前ZYBOで実験していたときの写真がこちら。


Jupter で操作した内容を IkaLog の映像インプットとして使えるようクラスを追加して、とりあえずだけども対応完了。
https://github.com/hasegaw/IkaLog/commit/5b6b9ce55e1ae32e57c2dd6f05ae20aa00c9b3fd

HDMIのキャプチャは実現できたが、PYNQにはHDMI Outputもあるので、こちらにパススルーすると、PYNQがIkaLogマシン+ビデオキャプチャ+HDMIスプリッタを兼ねるという、いままでIkaLogを利用するにあたって必要となる3つのアイテムをワンボードで実現できることになる。

Pynqのドキュメンテーションを読んでいると、じつは上記の設定でHDMIパススルーも実現できていることがわかった。上記の設定を行うとOut側がIn側のバッファからデータを受け取るようなかたちでパススルーしてくれる(プロセッサは通していないと思う……フレームバッファは通しているかも?)

というわけで、数時間でできちゃったIkaLog+PYNQ(キャプチャ機能+映像のみスプリッタ機能)。

Pynqで動くIkaLog、Project Inqと命名。Pynqの利用用途として思いついてはいたけども、思った以上に簡単に実装できてしまった。ここまでの成果については下記 WIki ページを見ていただければ再現できるはず。
https://github.com/hasegaw/IkaLog/wiki/en_Installation_Pynq

これをしばらく動かしてみるといくつか課題が見えてくる。

一つ目の課題は、HDMI Outputから出力された映像がたまに縦にずれたりする。たぶんHDMI映像の伝送が、ARMのDDR3メモリに置かれたフレームバッファを介していて、IkaLogが走っているとメモリ帯域やバス幅が足りなくなるんじゃないかと疑っている。

二つ目の課題は、HDMIのスプリッタ機能といっても HDMI 信号を音無しの DVI 信号としてピクセル情報に落とし、それを DVI 信号として HDMI ポートから出しているだけなので、音が消えてしまう。もちろんレイテンシの問題もあるし、キャプチャ機能はそのまま使うとしても、 HDMI Input から入ってきた信号をできるだけ忠実に HDMI Output に出力するよう変更したい。

Xilinx FPGAなのでHDMIのシリアル信号をISERDESE2で受けて、出力するときはOSERDESE2で送信している(はず)。これらを直結すればナノ秒レベルのディレイでシリアル信号をそのまま伝達できるだろうけど、ビデオキャプチャ機能も必要なので、dvi2rgb IPと共存することは考えないといけない。

とりあえずPYNQについてきたbase.bitは忘れて、dvi2rgb -> rgb2dvi でパススルーするデザインを作ってみた。



WiiU の信号が直接映らないのは相変わらずだけども、画像がたまに縦に1ドット間延びするような現象は解決した。ARMプロセッサ側のDDR3メモリを介さずに、受け取った信号をそのまま送出しているからだろう。

でも、やはり音のデータは消えてしまっている。

手元に高速ビデオ・インターフェース HDMI&DisplayPortのすべて という書籍があった。


これを読み返してみると、オーディオ信号はVSYNC直後のブランク期間などに入っているとのこと。ここが現状どうなっているかを調べると、色々解決しそう。 dvi2rgb がブランク期間中の信号を捨ててしまっているのではないかという想像だ。もし信号が捨てられていない事が分かればラッキーで、今度は送出側 rgb2dvi が信号を捨てていると考えればよさそう。

Integrated Logic Analyzer を追加して信号を眺めてみる。





案の定 dvi2rgb がブランク期間中の信号をゼロでマスクしているようだ。この 000000 になっているところに、本当はオーディオ信号も乗っているはず。ここにあるはずの信号も含めて rgb2dvi の OSERDESE2 に流し込んであげれば、きっとオーディオ含めてスプリッタとして動作してくれるだろう。

とりあえずの調査はここまで。

2016年6月15日水曜日

ルータがPPPoEで取得しているIPアドレスが変わったらRoute 53のレコードを更新するスクリプト

リモートから自宅のネットワークに接続できるようにしている方も多いと思いますが、ウチも出先からリモートアクセスしたりしています。

これまで外部の Dynamic DNS サービスに頼っていたのですが、利用していたサービスに変更があったのをきっかけに自前の仕組みに置き換えました。今回は、その仕組みについて紹介します。

私の自宅では RTX1100 が上流ネットワークとの PPPoE 接続を行っており、 pp 1 インターフェイスが外側のアドレスを持っています。このインターフェイスのアドレスを、自分が Amazon Web Services の Route 53 上で管理するゾーンのAレコードとして登録します。

ちょっと面倒だったのが RTX1100 の外側 IP アドレスの取得をどうするか、です。最初は 「SNMP クライアントでつっつけば出てくるじゃろ?」と適当に snmpwalk してみたのですが、よくわからなかったので、結局 telnet で調べるローテクで実装しています。

使っているコードのうち自宅依存部分を取り除いたものを https://github.com/hasegaw/route53update に Push してあります。


この中には3つのファイルが含まれています。

  • rtx1x00_show_status_pp_1.exp …… RTX1100 と telnet して IP アドレスを取得する
  • route53update.py …… 取得したアドレスを R53 に反映する
  • run.sh …… 実行方法

rtx1x00_show_status_pp_1.exp

RTX1100 に telnet して IP アドレスを取得します。このスクリプトは実際には RTX1100 と通信して、その内容を標準出力に書き出すまでです。実行には expect が必要です。引数としてホスト名とパスワードをとります。



route53update.py

上記 Except スクリプトを実行し、ルータからの出力を実際にパースし、 Route 53 のレコード内容と比較してみて、必要なら反映するのがこちらのスクリプトです。ファイル内にいくつか設定項目があります。(レコード名、 ゾーン名、ルータのホスト名とパスワードなど)
おまけで Slack にも対応しています。


 run.sh

route53update.py を実行する方法の例です。 AWS の API キーを設定しスクリプトを叩いています。手元ではこのスクリプトを cron に仕掛けています。


定期的にこのしくみが実行されることにより、Route 53 上の A レコードが常に自宅のルータに向くようになります。また、 Slack に新しい IP アドレスが通知されるため、ネットワークの不調に気づきやすかったり、などのメリットがあるかもしれません。

2015年12月10日木曜日

おうちハックで戦った話

この記事は おうちハック Advent Calendar の 10 日目の記事です。

前日の記事: Extreme Home Hackレポート
翌日の記事:メインブレーカーが落ちる前にドライヤーを止める

なんか面白そうなので参戦してしまいました。私は玄関ドアにネットワークカメラを設置したことがあるので、そのときの話を紹介したいと思います。


すべてのはじまり



隣人から、わたしの在宅、不在に関わらず「私の騒音がうるさい」というクレームがくるようになったのです。このクレームの一週間後、私は当時の勤務先の本社があるソルトレイクシティに出張する予定でした。このため、私が海外出張中でも物音がするのかを確認するため、急遽 Web カメラでインターホンの動体検出・録画を仕掛けました。


玄関カメラ1号


玄関のインターホンはカメラ付きで、誰かがインターホンを押せば、その瞬間に液晶画面に玄関前の映像が映ります。このため、インターホン設備の前にWebカメラを置き、MacBookに接続して、動体を検出したら自動的に録画するソフトウェアを見つけてきて仕込みました。

 
帰宅した自分自身も記録されています。

ここで使用したソフトウェアは、 YYYYMMDD_HHMMSS形式でJPEGファイルとして動体のフレームを保存します。このため、ファイルが保存されれば、いつ、誰が自宅のインターホンを押したかが記録できるわけです。

このソフトウェアの画像ファイル保存先を Dropbox に設定することで、私がアメリカ(現地時間の日中は、クレームがくる可能性がある夜間や朝)に滞在しているとき、手元の Dropbox ディレクトリ内に新しい画像ファイルが同期されてきて、リアルタイムに気づけることになります。

ついに隣人が私の家のインターホンを押しました。私は Snowbird というゲレンデで同僚とスノーボードを楽しんでいるのに、です。



これで私の無実は証明できました。しかし。しかしです。

3月3日 午前6時37分。当たり前ながら(?)私は寝ていました。そうすると突然インターホンが鳴り、いったい誰がきたのかと思ったら、例の隣人が「出てこい!」と切れています。何かが玄関ドアに対して当たる音がしました。きっとドアを殴ったか、蹴ったかのどちらかでしょう。びっくりしていると私の家の前から消えてしまったのですが、追いかけて事情をきくと、昨夜 23時〜0時にかけて物音がした事についてのクレームでした。

3月17日 午後10時30分。また下の階の住民が訪ねてきて、騒音がうるさい!とのクレーム。そのときは、まだ発売されたばかりの「シムシティ」を楽しくプレイしていた最中で、ゲームからショベルカーで建物をスクラップしたときのドーン音ぐらいしか発生させていませんが、それが下の階に届くことは考えづらいですし、自分自身はソファに座ってキーボードやマウスを操作しているのですから、騒音のたちようがありません。

どうにもならないので大家、不動産会社経由で管理会社に「隣人が騒音に苦しんでいるので助けてあげてほしい」と連絡をしました。これまでの経緯もあわせて、です。海外出張中の深夜に隣人が訪ねてきた記録が残っていることも話しました。


玄関カメラ1号、破れる


すると隣人のクレームがエスカレートしてきました。

 

3月23日 21時54分、インターホンのカメラ部分に手を当てて自分の姿を隠しながらドアを喚いたりドアを蹴ったりしています。どうやら記録の件が管理会社経由で伝わって気分を害したようです。仕方ないのでまた管理会社に連絡です。

管理会社に対応をお願いしつつ、私はインターホンのカメラシステムをアップグレードする必要性を感じていました。理由は:
  • 就寝中(午前2時〜4時)の訪問を繰り返されて、インターホンが鳴ったかどうかも正常に判断できなくなっており、客観的な記録はとり続ける必要があった
  • 先述の理由でインターホンのモニタ前にカメラを仕掛けても目的の画像が記録できなくなっていた
  • 在宅、不在にかかわらず隣人が自区画に近づいたかはログしておきたかった(訪問のほか、嫌がらせなどがあった場合の記録は残しておきたい)

玄関カメラ2号、爆誕


そんな時、秋葉原で在庫放出品と思われるネットワークカメラ PLANEX CS-W05NM があったので、買いました。


こちらは無線 LAN モデルになっており、 Web ブラウザからカメラのリアルタイムモニタリングをしたり、動体検出 SD カードや SMB/FTP によるリモートへの録画などが可能です。

早速、玄関ドアの覗き穴部分に取り付けました。築40年越えの分譲マンションのドアですが、ホームセンターで購入した玄関用覗き穴パーツ、木の板、ボルトなどをつかってマウントを自作します。賃貸契約ですし、オリジナルの部品は退去時に原状復帰できるようにすべてそのまま保管してありました。


しかし、新たな問題が発生しました。覗き穴経由の像は有効画素数の一部にしか映っておらず、結果としてネットワークカメラがもつ動体検出機能が動作しませんでした。動体検出の閾値は調整できそうにありません。


玄関カメラ2号のソフトウェア開発


仕方なく何か手段がないか探っていると、 設定次第では、ネットワークカメラに HTTP リクエストを送ると、Motion JPEG 形式でストリーミングが受けられることに気づきました。 Motion JPEG はいわば JPEG 画像のパラパラまんがですので、これをプログラムでバッファに書き出せば画像をリアルタイムで受信できるわけです。ネットを探検していたらサンプルコードを見つけたので Python で実装しなおし、二枚の画像を Numpy で引き算し差分を求めれば、画像の変化がわかるので、ニーズにあわせた動体検出&録画プログラムを書くことにします。

と、いうわけで。 Python と OpenCV を Hello world する日がきました。 Motion JPEG ストリームから JPEG データを抜き出し、 OpenCV を使って画像データ(Numpy)の配列に変換します。

あとは、すこし時間差がある画像2枚の差の絶対値をとれば、画像のなかで変化が大きいところが浮かびあがってきます。

この考え方をベースに、
  • Python で Motion JPEG のストリームを受信
  • 過去何十フレーム程度の履歴を常に保持
  • 過去のフレームと最新のフレームの差(=画像の変化)を調べる
  • 画像に変化がしばらく続いた場合に、バッファに残っているフレームから、画像の変化がなくなってしばらくするまでをひとつのMJPEGファイルとして保存
  • 検出開始した場合は Growl で手元の端末に通知
実際には蛍光灯のフリッカー、きまった時間に点灯/消灯する階段照明、カメラ自体のオートコントラスト/ゲイン機能などによる一時的な画面変化などを無視する処理もしています。

このソフトウェアが生成したビデオファイルの例を示します。

この仕組みにより、自宅の玄関に隣人が迫ってくる段階から記録を残すことができるようになりました。


玄関カメラ2号の運用結果


この仕組みでは、玄関の前を通った人たちも記録されてしまいます。見られていると思ったら周りの人々も気持ち悪いでしょうし、私自身も興味ない上に見ていてあまり気分のよいものではないので、目的の人物でなければ見なかったことにして忘れてファイルも消去です。そのほかにカメラを映りこんだ人を見てみると、
  • 表札をチェックしていく謎の男性 (地図屋?そのほかの調査?)
  • なぜか不在中に来訪した女性(たぶん宗教の勧誘とか)
  • 宅配便のスタッフ(チャイムを鳴らしながら電気メーターのまわり具合をみて在宅かどうかを見極めようとする人が多い)
などが見えてきて、いろいろと参考になりました。そして、ゴールデンウイーク。問題の隣人が夜に訪ねてきたビデオがついに記録されました。
問題の隣人が夜に訪ねてきたタイミング、および日中に手紙を玄関ポストへ投入する姿が覗き穴から確認できました。もちろんドアに近づくどころか階段を昇ってくる瞬間から動画として記録していますので、仮面ライダーのコスプレでもしていなければ誰であるかもよく判ります。

幸い、このタイミングで管理会社に改めて連絡をしてからは、隣人からクレームがくることはなくなりました。その後もしばらくこのシステムを稼働していましたが、さらに半年した時点でシステムを停止しました。今年にはいってからマンションの大規模修繕があり、玄関ドアごと付け替えになったので、先のネットワークカメラも今はありません。


関連するハック


このカメラですが、連続稼働していると突然通信できなくなることがあり、そのためにワッチドッグタイマーでリセットすることを考えて Eject-io というデバイスを開発していました。 Eject-io は カーネル/VM探検隊の Advent Calendar 2013 で紹介しましたので、そちらをご確認ください。
実際には Eject-io を使わずにタイマーを使って6時間ごとにネットワークカメラを起動しなおす運用を続け、それで目的が達成できてしまったので、 Eject-io は使いませんでした。


また、のちにスプラトゥーンの画面解析ツール IkaLog を作る際にはこの時の Python + OpenCV の経験が役に立ちました。

おわりに

ちょっとした手段で記録を残しても、いわゆるキ○ガイが静かになるかどうかは別の話だなあ、と思いました。

今回、私のケースは半年程度でに落ち着いたので(たぶん)よいのですが、火のついたマッチを玄関ドアの郵便受けに突っ込まれたり、その前に灯油がガソリンなどまかれたりしたら恐ろしいことになりますし、上の階に住んでいる子供達が心配です。

そういう自体を想定して火災アラームの増設などは行っていましたが、そもそも午前2時〜4時に度々チャイムを鳴らされて起こされていると、寝ている途中でふと「チャイムが鳴った気がして目が覚めたり、でも鳴っていなかったり、鳴ったのか鳴っていないのか判らなかったりしてきて、認識に異常をきたします。正直なところ、そもそも、そんな心配がないところに移ったほうがいい、と思っています。

おうちハック自体ではキ○ガイは居なくなりません。皆さん、お気を付けください。

おうちハック Advent Calendar の 10 日目
前日の記事: Extreme Home Hackレポート
翌日の記事:メインブレーカーが落ちる前にドライヤーを止める


2015年8月24日月曜日

FreeNX で新規セッション生成時の不具合を解消する

いまごろ FreeNX 使っているところはそう多くないだろうし、完全に手元のメモだけど。


nx ユーザとしての localhost SSH 接続時にホスト鍵が一致しない場合の問題


FreeNX の認証方法にもよるが SSH 認証を使う場合、一度 NX ユーザとしてログインし、その NX ユーザから実際のユーザ権限で目的のサーバ(localhostかもしれない)に対して SSH ログインする仕組みになっている。

OS のイメージをコピーしたりする際、 ~nx/.ssh/known_hosts に localhost の鍵が含まれている。このため、 同ファイル中の「localhostの鍵」と/etc/ssh/の下にあるホスト鍵が一致しなくなると認証エラーとなりログインできない。うっかり設定をコピー展開したりSSH鍵を作り直したり、イメージを作成して展開した場合に嵌まる。

 対策としては ~nx/.ssh/known_hosts を消す。(と現行の鍵が勝手に書き直される)

 X ディスプレイのロックファイルが蒸発した場合に、新規セッションのディスプレイIDが既存セッションと衝突する


該当箇所は /usr/bin/nxserver のココ


FreeNX や X Window System の何かが /tmp/ 以下にロックファイルを作っている。 FreeNX の新規セッション作成時は、これらのファイルからディスプレイ番号の利用状況を判断して新しいディスプレイIDを割り当てる。

たとえば nxserver --list コマンドで下記のセッションがあるとして

127.0.0.1    1005    hasegaw    192.168.x.x    23BC130AD583AD79F715814CE73972B5

以下のロックファイルがひとつも見つからないと、NX Clientから接続された FreeNX は、重複したディスプレイ番号をセッションに割り当てようとして突然死し、ユーザから見ると何もわからない状況になる。
  • /tmp/.X1000-lock
  • /tmp/.nX1000-lock
  • /tmp/X11-unix/X1000
対策として、下記のワンライナーで、 nxserver --list の結果から、足りないロックファイルを生成するシェルスクリプトを生成させてシェルに流し込む。ひどいけど動いてる。


本当は nxserver を直さないとダメかと思ったけど、RPMから導入してるものをいじらずに対策できてよかった。っていうか自分でディスプレイ番号わかってるのに重複割り当てするとか情けない。。。。

おもうこと


Linux 向けのリモートデスクトップ環境として FreeNX(や X2GO)は割と快適なんだけど、いろいろ罠があってつらい。もっと鉄板なソリューションはないものか。。。

2015年6月8日月曜日

fluent-bit 用 AM2320/AM2321 Input Plugin

LinuxCon 2015 Tokyo の発表を見ていたら、今後、 IOT デバイスや組み込み機器などを想定した fluent-bit で、センサ関係をサポートしていくらしい。折角なので、とりあえず自宅の温度・湿度計測に利用している AM2320 の Input Plugin を書いてみた。

AM2320 は秋月電子で入手可能な温湿度センサ。 I2C 準拠なので Raspberry Pi に 4 線つないであげれば利用できる。たぶん AM2321 というのは AM2320 のピッチ違いバージョンだと思う。 AM2320 が 2.54mm なのでブレットボードやユニバーサル基板に実装できる。

※ Raspberry Pi のユニバーサル基板に真面目に実装すると RPi 側の発熱を拾ってしまうのでアレ。

もともとは Raspberry Pi で AM2320/AM2321 を使うプログラムの Mackerel対応版 をベースに温度、湿度が取得して、それをエージェント経由で Zabbix に突っ込んでいたんだけど、記録だけなら fluent-bit のほうがシンプルな ので、プラグインを起こしてみた。

Raspberry Pi の I2C ドライバをロードしておき /dev/i2c-1 が見えている前提で、下記の要領で利用できる。

2014年5月22日木曜日

ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々

先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると:
  1. ファイルシステム上に書き込み可能な状態でファイルをオープンする。
  2. 一定ペースで、ファイルへ Buffered I/O で書き込み。
  3. ファイルをクローズする。
このとき、特定条件下のXFSでは、(2)の段階では全然フラッシュが発生せず、(3)の段階でまとまったフラッシュが発生するのだそうです。

ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション(ミドルウェア)からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linuxでは5秒ごとにメモリ上のダーティーなページがファイルシステム上に反映されるというのですが、今回はそのような動作になっていないようです。

またお話を聞いていると、
  • Ext3 でフォーマットされた、ハードディスク上の / では現象が発生しない
  • XFSでフォーマットされた、 ioDrive 上の /data (仮) では現象が発生する
  • ioDrive + VSL2, ioDrive2 + VSL3 のどちらでも発生する
    ※ VSL = Virtual Storage Layer; ioMemoryシリーズ用のドライバソフトウェア
とのことです。

Linuxカーネルの配布元、リリース、利用するファイルシステム、利用する ioDrive シリーズとドライバやファームウェアのバージョンなどによって食いあわせ的な問題も経験したことがあります。

ただ、今回の場合、ここまでの情報より、そもそもブロックデバイスへのI/Oがきていない(であろう)こと、 VSL2 と VSL3 で問題が再現するということから、個人的には、カーネル側(Linuxのブロックレイヤやファイルシステムドライバ)の挙動なのではないか、と切り分けました。

以下が、今回相談いただいた問題の再現例です(検証は ESXi 上の CentOS 5 で行っており、また ioDrive は利用していません)。



ioDrive を使っているユーザーさんは、こういう細かな問題も乗り越えながら日々運用していらっしゃるんだなあ、と思うと、頭が下がる想いです。


ところで、私は ioDrive をはじめとする ioMemory のベンダーである Fusion-io に務めていますが、いまのポジションでは、このような"カーネル依存"やOSのデザイン上のご相談なども度々いただきます。OS/ミドルウェアなどの動作上の問題:ioMemory の動作上の問題の割合=4:1、もしくはもっと前者の割合が多いように感じています。

Fusion-io のエンジニアをやっていると、ioMemory をいじっているよりも、関連するソフトウェアを弄っていることのほうが多かったりします。もともと ioMemory を使うユーザーは「ioMemoryの性能を限界まで使いたい」とはちっとも思っていなくて、「 ioMemory を使ってシステムを快適にしたい」「運用を改善したい」という動機であることが多いはずです。

幸いにも、この会社が持っている ioMemory シリーズは、半導体ストレージとしては業界トップクラスの性能ですから、デバイスの性能自体にあまりナーバスになる必要性はありません。お恥ずかしながら、実際、私は ioMemory のIOPSスペックをひとつひとつ憶えていませんし、する必要もありません。 ioMemory のスペック値を憶えても CPU やメモリのパフォーマンス、システムボードの設計で実際に利用できる範囲は下ブレも上ブレ(!)もしますし、トラブルシュートでデバイス側に執着しても解決するものは少なく、システム上でソフトウェアがどう動いているかに注目しなければ、大抵の問題は解決しないと思います。

 私自身がプラスアルファの活動に費やせる時間には限りがありますし、自分の”守備範囲”はお世辞にもそれほど広くないので、限界があります。ですが、自分ができる範囲で、 ioMemory ユーザーにはデバイスだけでなく、関連する”ソフトウェア側の落とし穴”もうまく乗り越えて、確信をもって使ってもらえるようなれば、と思っています。

2014年5月9日金曜日

Fusion-io ioDriveの状態をohaiで取得する

ohai プラグインを書きました。

ioMemory VSL3.x 専用です。 ioDrive 第一世代向けの旧リリースである VSL2.x では使えません。

2014年4月17日木曜日

「改定新版 サーバ/インフラエンジニア養成読本 仮想化編」に寄稿しました。

 技術評論社から発売となった、改定新版 サーバ/インフラエンジニア養成読本 仮想化編に、過去の記事が寄稿しました。基本的には2011年当時に機会をいただき執筆させていただいた「KVMの基礎知識」という記事の再録ですが、昨今の OpenStack をはじめとするソフトウェアの登場にあわせ多少アレンジしました。書店で見かけましたら手にとっていただけますと幸いです。





VMMまわりの記事を書いているのは大体、昔あった仮想化友の会の人々ですね。:)