2013年12月16日

最近のCPUでは乱数生成がはやい話

Ivy Bridge以降のCPUではCPU内に乱数生成器が含まれています。それに対応した最近のrngdをつかうとそれなりに乱数生成が速くてしあわせになれます。

linuxでは乱数を取得するために /dev/random と /dev/urandom の2種類のデバイスがあります。それぞれの説明は man 4 random にみっちり書いてありますが、かいつまんで言うと:
  • random: カーネルがあつめてきたノイズを元に品質の高い疑似乱数を生成します。ノイズが不足するとblockします。
  • urandom: カーネルがあつめてきたノイズを元にそこそこの品質の疑似乱数を生成します。品質はそこそこですがblockしないので速いです。
ためしにcat /dev/random とかすると1kとか4kくらい乱数が出力されて止まってしまう。これでは割と足りないので選択肢が2種類。1) 品質をあきらめてurandomを使う、2) 乱数生成器をつけてrngd経由で書き込みとエントロピーの追加をおこなう。乱数生成器は一部のチップセットに内蔵されたりしてたんですが、 専用ハードウェアもあったりします。

いいかげんな乱数でよければurandomなのですが、sshのキーをつくるとかsslちゃんとやろうとか証明書発行しようとかしたいときは/dev/randomをつかいたい、でも周辺装置とかチップセットの制約とかめんどいなー。 という事情がありました。

そこでIvy Bridge世代ではrdrand命令を追加して、CPUのチップ内で乱数生成をして専用命令で読みだせるようにしました。このテクノロジー自体もかなりおもしろいです。IEEE Spectrumの記事がおすすめ。


実際つかってみましょう。rngdの最近のバージョンでは、rdrand命令に対応しています。最近のfedoraであればデフォルトでrngdが動いていますが、有効でなければ systemctl start rngd.service とか叩いて有効にします。

ddで1バイトずつ乱数読みだしをおこないます。乱数生成器がない環境とかrngd止まってるとかだとこれがblockしてずーーっと待つことになるので注意。
$ dd if=/dev/random of=/dev/null bs=1 count=1000000 
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 4.32184 s, 231 kB/s
 比較対象としてurandomでも同じことをしてみましょう。
$ dd if=/dev/urandom of=/dev/null bs=1 count=1000000
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 1.3472 s, 742 kB/s
urandomのほうがまだ速いですけど1/3くらいの速度はでますね。これくらい出てくれるなら乱数つかい放題といってもいいんじゃないかしら。


2013-12-16追記
Debianではrng-toolsが独自forkなためrdrand対応がまだ入っていないらしい。rng-toolsのアップデートについてのケースがfileされている。一方UbuntuにはDebianはforkだから独自に新版入れてくれというケースが。Debianの動き悪いのはわかるけどUbuntuだけ対応するってなんだかなあ。

2013年12月15日

/proc/cpuinfoを目で読むのがつらい

最近のコンピュータだとCPUのコア数やスレッド数が多いので/proc/cpuinfoを直接読むよりまとめて出力してくれるlscpuやhwlocをつかったほうがよい。

最近コア数とか多いですね。デスクトップでもCore i7だと8スレッドとかありますしサーバだと4ソケット40コア80スレッドとかあります。

CPUがどういう構成なのか知りたい時は /proc/cpuinfo  や /sys/devices/system/cpu/* を読むことが多いですが表示が冗長なのでつらいです。そこで適当にまとめて表示してくれるコマンドが便利です。


lscpuはCPUのキャッシュ構成とか、ソケット-コア-スレッドの個数の関係がわかります。実機で数回実行するとわかりますがCPU MHzのところは実際の周波数にあわせてちょいちょい変わるのでアテになりません。
出力はこんなかんじ:
$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Stepping:              9
CPU MHz:               1802.000
BogoMIPS:              6784.54
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7
hwlocは本来はNUMA環境などをうまく使うために適切なtaskset等を生成したりするためのツールセットなのですが、今回は表示してくれるところだけ見ます。グラフィカルなのが好きな人はいいんじゃないですかね。
  $ hwloc-ls -p

以下はしばらく前にとった4ソケットマシンでのhwloc-lsの出力。「でかい!」ってことしかわからない気もします。。

2013年12月10日

広告消した

なんとなくつけていた広告、自分はadblockを使っていていつもみていないんですが人のブラウザで自分のblogを見たらかなり鬱陶しかったので消しました :)

2013年12月7日

SSDの寿命をext4ファイルシステムの統計情報から推定する

SSDを選定する場合には書き込み量の推定が重要です。 

NAND Flashの各ブロックに書き換え回数の上限があるSSDでは書き込み総量に制限が存在します。
NAND Flash自体の書き換え回数上限は実装にどのような技術が使われているかにもよりますが数千回から10万回程度。HDDやRAMDISKではこの回数上限は事実上存在しません。

そのためSSDではファームウェアで各ブロックが均等に書き換えられるように工夫したり、外部に見せるより多い容量のNAND Flashを用意してブロックあたりの書き換え回数を減らしたり、不良ブロック発生時にもただちに影響がないようにしています。

このため、コンシューマ向けでは記載がないものもありますが、エンタープライズ向けSSDでは必ず総書き込み上限について記載があります。

適当にぐぐったIntelのSSD仕様の例: http://ark.intel.com/ja/products/75682/Intel-SSD-DC-S3500-Series-300GB-2_5in-SATA-6Gbs-20nm-MLC

耐久性評価 (書き込み上限数) 170 TBW 
この例では170TB書きこみできます。
170TB / 300GB =  566.66... なので、566回程度ディスク全体を書き換えられる。。 といわれてもまったくピンときませんよね。

たとえば想定される利用期間に対してトータル+安全係数で200TBくらい書きそうな場合にはこの製品よりグレードの高いものを選ぶべきです。しかしHDDでは書き込み回数に上限がなかったこともあり、これからSSDを使おうという場合に、書き込み容量総計についてはノウハウが無いまたは少ないケースが多いです。書き込み量がどのくらいかは完全にワークロード次第でかわり、負荷が高めのDBや、仮想マシンの作成・削除を頻繁に繰り返すような環境では非常に大きくなりえます。


ext4では2009年に導入されたパッチでファイルシステムへの書き込み総量を記録する機能をもつようになりました。この情報はdumpe2fsで確認できます。以下はHDDの例ですが、出力中の Lifetime writes:というフィールドがそれにあたります。
# dumpe2fs -h /dev/mapper/backup-backup
dumpe2fs 1.42.8 (20-Jun-2013)
Filesystem volume name:  
Last mounted on:          /var/spool/backup
Filesystem UUID:          fc89edc2-fab9-4d35-9761-f0fd60f6c171
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488377344
Reserved block count:     24418867
Free blocks:              196290282
Free inodes:              121615201
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Nov 28 10:04:04 2010
Last mount time:          Mon Nov  4 09:50:05 2013
Last write time:          Mon Nov  4 09:50:05 2013
Mount count:              94
Maximum mount count:      34
Last checked:             Sun Nov 28 10:04:04 2010
Check interval:           15552000 (6 months)
Next check after:         Fri May 27 10:04:04 2011
Lifetime writes:          5899 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11

(以下略)

3年で5899GBほど書いています。月あたりの書き込み量を概算すると
6000GBの書き込み / 36ヶ月 = 166GBW/月
となり、ディスクの寿命を5年とすると
166GBW/月 * 60ヶ月 = 9960GBW
となります。書き込みの使われかたがおおよそ安定していると想定すると、10TBWほど。さきほどのintelのSSDを使えば余裕ですね。



2013年8月27日

Androidのメディアストレージによるキャッシュを更新する

Androidに.oggや.mp3ファイルを転送して、そのあと適当に違うフォルダに移動したりすると再生ができなくなる問題にハマったのでメモ。

この問題の原因は、Androidの「メディアストレージ」というプロセスがファイル転送直後にファイルをスキャンして「xxというアーティストの、yyという曲は、ファイルシステムのzzにあるよ」とキャッシュに記録するのですが、この情報がファイル移動時に更新されないために、キャッシュと実際のファイルの位置がずれてしまうことです。

対策としては以下の2パターン:
  • メディアストレージに「キャッシュを更新して!」とお願いする
    • Force Media Scan というこれだけを行うアプリがあるのでインストールしてボタンを押す
  • メディアストレージのキャッシュを消して作り直させる
    • 「設定→アプリ→すべて→メディアストレージ」を探してデータを削除したあと、再起動する

XFSの想定Q&A

RHEL 7のデフォルトファイルシステムがXFSになるので想定FAQを twitterでつぶやいた まとめ
  •  ext3/ext4からフォーマットせずにxfsへ移行できますか?
    • →できません。バックアップのリストアによる移行をおねがいします
  • RHEL7でext3/ext4はつかえますか?
    • →引き続き利用可能です
  • XFSで十分でかいとこまでいけるけどRHS買う必要あるの?
    • →パフォーマンスや冗長性の要件にあわせてお選びください
  • XFSって実績あるの?
    • →はい。RHEL5に対する追加製品、RHEL6のAdd-onとして過去数年販売しており実績がございます。もし何か問題があればサポートにご確認ください。
  • XFSってX font serverとまぎらわしい
    • →そうですね
  • XFSって16EBまでいけるってwikipediaに書いてるよ
    • →サポート上限は実際に検証したサイズなので論理的な上限より小さいです
  • XFSって何の略?
    • →すいませんわかりません
  • XFSって縮小できないけどどうしたらいいの
    • →ストレージかLVMのthin provisioningでご対応ください
  • XFSってスタック食い潰してカーネルごと死ぬんじゃね?
    • →2010年くらいに知られた問題は既に解決していますが、なにかあればサポートまでご連絡ください
  • xfs_repairってメモリ食い潰すんじゃね?
    • →2010年1月の3.1.0で消費メモリ量は縮小したそうですがやはり何かあればサポートまでご連絡ください

2013年8月26日

RHEL5 AP を更新したいが何を買えばよいか?

RHEL5 APを利用していた場合、RHEL Server, High Availability Add-on, Resilient Storage Add-on, Load Balancer Add-on のチャネルが使えるはずです。 この中で必要なものを選択して更新をおこなうことになります。

RHNの情報があまり役に立たない話

RHEL AP 5 をinstallation numberを利用してRHNへ登録した場合、関連するadd-onのチャネル全てを購読するよう設定されます。
一方RHEL AP 5 をinstallation numberを利用*せずに*RHNへ登録した場合、関連するadd-onは設定されず、Serverチャネルのみ設定されます。
そのためRHN上では実際の利用状況ではなく、どのように登録したかということだけがわかる状況です。

実際の利用状況を確認する方法

実際の利用状況から必要有無を判断する必要があります。幸い各add-onは比較的「知らない内に使っていた」ということが起きにくい製品群です。簡単な識別方法について以下に記します。

用途に該当して、関連パッケージを利用していれば add-on が必要です。
  • load balancer add-on
    • 用途: サーバをIPロードバランサとして利用している
    • 関連パッケージ: piranha, ipvsadm
  • resilient storage add-on
    • 用途: クラスタを構築していて、共有ディスクを利用しGFS・CLVMのいずれかを利用している。iSCSIターゲットとして利用している
    • 関連パッケージ: kmod-gfs, lvm2-cluster, scsi-target-utils
  • high availability add-on
    • 用途: フェイルオーバクラスタを構築している
    • 関連パッケージ: rgmanager

RHEL6に含まれるruby 1.8.7はいつまでサポートされますか?

RHEL6に含まれるrubyパッケージは、RHEL6のライフサイクルに従いサポートが提供されます。rpmパッケージであってもRHELに含まれないものや、お客様自身で再ビルドしたもの等はサポート対象外となりますのでご注意ください。

ライフサイクルは期間によってフェーズが分かれ、段階的にサポートレベルが変わります。脆弱性およびバグの修正については運用3フェーズまで提供され、2020年11月30日まで提供されます。

ライフサイクルの詳細については以下のwebページにてご案内しておりますのでご確認ください。
https://access.redhat.com/support/policy/updates/errata/

Red Hat Enterprise Linux 6のEOL日程はいつ公開されましたか?

RHEL6発表当時はライフサイクルの運用フェーズは7年間と定義されておりました。そのためお客様の利用開始時期(2011年末)にはRHEL6の運用フェーズ終了を2017年11月までと宣言しておりました。

その後2012年1月31日にサポートポリシーを変更いたしまして、10年間のライフサイクルとし、運用フェーズの終了は2020年11月としております。

ライフサイクル変更当時のプレスリリースは以下でごらんいただけます。
http://jp.redhat.com/about/news/press-archive/2012/1/red-hat-enterprise-linux-stability-drives-demand-for-more-flexibility-in-long-term-operating-system-deployments

RHEL HA Add-onのハードウェア要件について

HA Add-onを利用する場合、通常のRHELがサポートされている環境だけでなく、それに加えてfence deviceと呼ばれる追加のハードウェアが必要となります。

典型的に利用されるfence deviceは、IPMI規格による電源管理、各ベンダー規格による電源管理(iLO, DRAC, RSA)、外部電源スイッチ(WTC, APC)などです。多くのサーバ向けハードウェアでは対応する機能を内蔵または別売で利用できます。

fence deviceを利用しない構成は、HA Add-onのサポート対象から外れてしまうのでご注意ください。

fence deviceについては、以下のページにてご案内しております。

フェンス設定ガイド フェンシング
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Fence_Configuration_Guide/ch-fencing.html
Cluster Administration 互換性のあるハードウェア
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/s1-hw-compat-CA.html
ハードウェア種別毎のサポート状況一覧表
http://www.redhat.com/cluster_suite/hardware/

RHELでのセキュリティイベントをログに保管したい

認証についてはPAMに pam_warn モジュールがあり、認証の成功・失敗、認証を要求したプログラム、端末、ユーザ名、接続元の情報をsyslogに出力します。

pam_warnモジュールについては弊社ナレッジベースの以下の記事でご案内しております。
https://access.redhat.com/site/solutions/58736


またSELinuxのポリシーで定義されたイベントは、/var/log/audit/ 以下にログとして記録されます。SElinuxのポリシーで許可されていないアクセスがあった場合にこのログを検出してアラートを出力する機能を提供しております。

以下のドキュメントでこの機能についての概要をご案内しております。
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security-Enhanced_Linux/index.html#sect-Security-Enhanced_Linux-Working_with_SELinux-Which_Log_File_is_Used


最後にRHELのセキュリティ関連ドキュメントをご紹介します。

セキュリティガイド
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/index.html
SELinuxユーザーガイド
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security-Enhanced_Linux/index.html
Managing Single Sign-On and Smart Cards(英語)
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Managing_Smart_Cards/index.html

RHELのアップデートをオフラインでおこないたい

RHELサーバをインターネットに接続せず、オフラインでアップデートを行いたい場合、以下のような関連製品が存在します。

完全にオフラインで運用できるものとしては Red Hat Network Satellite を、
プロキシとして動作するものとして Red Hat Network Proxy, Subscription
Asset Manager を提供しております。

Subscription Asset ManagerはRHEL Serverをご購入であれば追加費用なしで利用できますのでご検討ください。

RHELでのブロックデバイスの名前を固定したい

RHELでのブロックデバイスの名前には、複数の種類があります。

よく見る /dev/sda1 などのデバイス名は安定していません。Linuxカーネルがデバイスを検出した順番にa,b,c,d,e... と名付けるため、デバイスの初期化順序がなんらかの理由で異なると、再起動時に異なる名前が付与される可能性があります。


RHEL5.3以降であれば、/dev/disk/by-id/ 以下に、ディスクのIDに由来して生成される永続的な名前のシンボリックリンクが生成されます。このファイル名は再起動により変わることはありません。


ストレージ管理ガイドに詳細が記載されておりますので参照ください。

RHEL6.4はHaswell世代のCPUに対応していますか?

対応しておりません。
RHEL6.5で対応予定です。

2013年8月23日

プログラマ格言(2006)

2006年くらいに書いたプログラマ格言が発掘されたのでおいとく。おおむねダジャレです。

 * PHPを笑うものはPHPに泣く
   * 意味: 「PHPなんてまともなプログラミング言語じゃないよ」と笑っていたら仕事でPHPを触るはめになってしかも既存のソースが汚かったりして泣く。
   * 教訓: 好き嫌いを通せるようにえらくなれ。

 * ソースが知れる
   * 意味: 変な挙動をするソフトをさわっていると、動き方から間違ってるパターンと作った人のレベルがなんとなく透けて見える。
   * 教訓: どうやったらうまく動くか探すのも仕事のうちらしい。

 * ひいきのwiki倒し
   * 意味: 「wikiはすばらしいツールですよ!」 と、とにかくwikiを導入してメンテ不良のページを大量につくってしまう。
   * 教訓: 情報共有ツールは使う人のメンテナンス能力が一番のネック。

 * ライブラリからボタ餅
   * 意味: 延々ぐぐってみつからなかった情報がライブラリのソースであっさりみつかった。
   * 教訓: ライブラリのソースは貴重な情報源。

 * UMLの大木
   * 意味: やたら継承ばっかりしていてすごい大木になっているクラス図を見てげっぷがでる。
   * 教訓: 実装の再利用は依存関係の拡大に注意。

 * 要求仕様と秋の空
   * 意味: 要求仕様は秋の空のようにかわりやすい。
   * 教訓: わかってるつもりの人が一番の危険人物。

 * KnuthもTeXの誤り
   * 意味: あのKnuth大先生ですらTeXで何個かバグを作り込んでしまったように完璧ではない。
   * 教訓: 我々はプログラムにバグを必ず作り込んでしまう。

 * とりつくcoreもない
   * 意味: 反応なくなったから再起動したよ、とか運用してる人に言われたけどログは正常処理しかでてないしcoreはないしどうにもしようがない。
   * 教訓: 何もないとこまるときは、backtrace吐いてくれるようにしとくだけでもだいぶしあわせ。

 * 臭いバグに蓋をする
   * 意味: バグっぽい挙動の原因を追及せずにとりあえずのworkaroundなパッチを書いてごまかす。
   * 教訓: 「発現しなければバグではない」が通用{する|しない}世界もある。

 * IDE屋のvi使い
   * 意味: 客にはIDEを売るけど自分はviでソースを書く。
   * 教訓: 使いやすそうなものと使いやすいものは別

 * コードは一日にして成らず
   * 意味: まともなコードは何年もかけて細かいノウハウや互換性対策などが積み重なっている。読んですぐ書けそうな気がしてもなかなかすぐには同等のものはできない。
   * 教訓: 「既存のコードを全部捨ててやりなおし」はけっこう大変。

 * 大山鳴動して虫が一匹
   * 意味: 大騒ぎになる酷い障害も、原因はくだらないバグ1個だけだったりする。
   * 教訓: 騒がなくていいからまず原因を調査。

 * コピペも山のにぎわい
   * 意味: 行数で単価が決まる案件では長いだけで無意味なコピペコードが良いということになってしまう。
   * 教訓: 行単価という評価基準はヤバスギ。

 * デザパタ読みのデザパタ知らず
   * 意味: GoF本を読んだひとが「デザインパターン使うぜ!」と、設計に無理矢理デザインパターンを盛り込んで変な設計になってしまう。
   * 教訓: 自然な適用をするためにはそれなりの修行が必要。

 * 犬も歩けばバグに当る
   * 意味: あんまり期待せずにウォークスルーをすると意外にバグがどんどんみつかって効率よかったりする。
   * 教訓: 時には無心にコードを読むのもアリ。

 * 一寸のバグにも五分の魂
   * 意味: ちょっとしたバグにもそれを作り込んだプログラマの勘違いや仕様の誤解など、幅広く影響しそうな背景がある。
   * 教訓: 「なんで?」を5回繰り返そう。

 * デバガとハサミは使いよう
   * 意味: デバッガに意外な便利コマンドがあったり、ソースを印刷した紙をハサミで切って並べてみるなど、プログラムを改良する方法にはさまざまなテクニックがある。
   * 教訓: 既に知っている道具もちゃんと調べるといいことがあるかも。

 * 地震,雷,火事,停電
   * 意味: 人間以外にも怖いものはある。
   * 教訓: このへんはマシンをデータセンターに置けばある程度避けられる。しかし人間は…!!

 * バグぶつかるも他生の縁
   * 意味: たまたまバグにぶつかっただけといっても、何かの縁なのだからバグレポートをしてあげよう。
   * 教訓: バグからはじまる恋もある(ねーよ

 * docを食らわばソースまで
   * 意味: ドキュメントを調べだしたらついでとばかりにソースまでよんでしまう。しかも本題と関係ないコードが理解できなくてなやんだりする。
   * 教訓: まずはFAQよんどこう。

 * ソースに入ってはソースに従え
   * 意味: 人のソースを変更するときはその人のコーディングスタイルに従って変更しよう。
   * 教訓: コーディングスタイルへの過度のこだわりはよくない。

 * 馬子にもGUI
   * 意味: つまんないプログラムでもGUIをつけるとそれっぽくみえるらしい。
   * 教訓: それっぽいだけかも。

 * 溺れるものは2chをも捕む
   * 意味: ハマってどうにもならないとき、2chの質問スレに頼る。
   * 教訓: とりあえず情報の裏はとっとけ。

 * 虎穴に入らずんばバグを得ず
   * 意味: (よくわからなくて怖い)フレームワークやlibcやカーネルの中まで読みこまないとバグを完全につきとめることはできないこともある。
   * 教訓: ソースさえ読めばそれなりにわかったりする。きにせずよんじゃえ。

 * 書いたコードに手をかまれる
   * 意味: ライブラリがおかしいのかとおもって延々調べても悪くなさそう。サンプルコードはちゃんと動く。まさかと思ってよくよく見ると自分が書いて大丈夫だと思ってたコードが間違えていた。
   * 教訓: それがバグ。

 * LL三年Web八年
   * 意味: どんなにLLを覚えても結局はWeb技術そのものに明るくなるために何年もかかってしまうということ。
   * 教訓: Webとブラウザ周辺は魔窟。

 * 能あるプログラマは爪を隠す
   * 意味: 有能なプログラマは、ほとんど「凄い」コードを書かないものである。
   * 教訓: 平易なコードの作者を甘く見るな。

 * 芸は身をHaskell
   * 意味: Haskell みたいなマイナー言語を使えるとかえって職にあぶれない。
   * 教訓: いろいろなプログラミング言語さわるとよい。

 * 多言語は無言語
   * 意味: いろんな言語にとりあえず手をだしてどれも中途半端にしかできないこと。
   * 教訓: 言語の深いところはあまりかわらないので、一つを極めてから他に手をだすとよい。

 * 案ずるより書くが易し
   * 意味: どの実装方針がいいかなあ、と迷うより書いてしまうほうが簡単。
   * 教訓: 迷ったら全部実装して比較。

 * 悪設計は百年の不作
   * 意味: 悪い設計を許してしまうとあらゆる場面で無駄な苦労をしてしまう。
   * 教訓: 設計は経験と能力の両方がある人にお願いしよう。

 * abで鯛を釣る
   * 意味: 「ab(apache bench)で性能測定」のような仕事のほうが意外に金をとれたりする。
   * 教訓: 自分的にたいしたことないスキルでも相手にとって価値があれば金になる。

 * makeるが勝ち
   * 意味: make一発でいろいろできるように自動化するとかなり便利
   * 教訓: 客の仕事だけでなく自分の仕事も自動化しよう

 * 転ばぬ先のテストケース
   * 意味: 先にテストを書いておけば防げるバグは多い。
   * 教訓: サボらずテストケースを書こう。

2013年7月17日

KVMで複数VMを起動してVM間の相互作用を減らしたいときに考えること


  • numadの利用(2ソケット以上のハードウェアを利用する場合)
    • 複数ソケットのサーバはNUMA構成なので、できるだけ他ノードへのアクセスを減らしてやるとよい。CPU使用率が高くなるとたまたまちょっとヒマになったCPUにマイグレーションする可能性があがるためnuma nodeにVMを割りあててやりたい。
    • 従来はベンチマークなどでvCPUのpinningなどが使われていたが、人間が指定するのではダイナミックに変化する状況に対応できないためあまり実用的で はなかった。numadはワークロードを見て、メモリとCPUの割り当てをnuma nodeに寄せる作業を自動的におこなってくれる。 
    • 起動直後に即座に影響がないのでちょっと気持ちわるい
  • CPUのオーバーコミットをする場合、Xeon 7500/6500 + RHEL 6.2以降の利用(Pause-Loop Exiting対応)
    • あたらしい世代だとどのCPUが対応してるんだろう……?
      • https://github.com/qemu/qemu/blob/master/scripts/kvm/vmxcap を実行するとVMXの機能一覧をだしてくれるので、今つかっているマシンがPLE対応かどうか判定できる
    • 仮想化環境でCPUのオーバーコミットをする場合、あるvCPUがロックを掴んだまま実行を停止し、他のvCPUではそのロックを待つためスピンロックしているケースが発生する。
    • PLEはスピンロックのように見えるタイトなループを検出すると仮想マシンを停止してハイパーバイザに制御をもどす。同一VMの別スレッドにスケジュールすることでロック開放を待つためだけに多量のCPU時間を消費することを防ぐことができる。
    • VMwareが従来複数vCPUをもつVMについて、全vCPUを同時にスケジュールするようにしていたのはおそらくこの問題を回避するためではないかしら(予想)。
    • KVMはLinuxのスケジューラそのままなので各CPUは基本的に独立してスケジュールされるのでこの仕組みは大変よくきく。
  • メモリはオーバーコミットしない
    • メモリをオーバーコミットするとろくなことがありません。なので要るだけ積みあげます。安いし。
      • ホストでのswapの発生によるVMから全く制御できない遅延
      • 複数台ある場合の性能のブレ
      • 特にゲストOSがlinuxの場合、メモリはあるだけ使おうとする。本来だとキャッシュとしての有効活用になるキャッシュを積極的に使う戦略が、メモリオーバーコミット環境下ではswapを多発させる原因になってしまう
    • qemuのためにこれに加えてVM数x1GBくらい追加メモリを用意する(200から500MBくらいでいい気もしますが余裕をもって1GB)
    • メモリは足りてるはずなのでKSMは停止する
    • (optional) hugetlbfsの利用
      • どうせVMに割りあてたメモリをswapさせないしさせたくない
      • 事前に計画できるならtransparent huge pageより低コスト
    • 結論: とにかくちょっと余るくらいメモリ積んどくといいよ
  • NICはSR-IOVか物理的に分けてmacvtapでつなげる。bridgeを共有しない。
    • ソフトウェアbridgeのコストは馬鹿にならない。ネットワークのレイテンシ増加とホスト側でのCPU消費の増大に直接繋がる
    • SR-IOV対応NICはブリッジ機能もオンボードで提供していることがある
    • パフォーマンスだけ考えれば、macvtapで繋げずにPCI passthroughで接続してもよい。だがその場合VMをマイグレーションできなくなるので注意が必要。
  • ブロックデバイスのバックエンドにファイルシステムやLVMはつかわず、個別にLUNを切る。
    • ファイルシステムのジャーナル処理が、ゲスト側とホスト側で2重になるのはほぼ利点がないがコストは高い。

2013年1月16日

RHEL for HPC はいつ使えてどういう違いがあるの?

HPC製品が適用できるユースケースについて
エンタープライズ契約の 1.A 表4内にHPC製品が適用できるユースケースの定義が
含まれております。以下に引用します。

> 以下のすべての特徴を持ち、数値計算を処理するためにネットワーク化およ
> び管理されているシステムで、最小単位で4つのシステム(「クラスタ」)
> から構成されている高性能コンピューティング(「HPC」)。
> (a) そのクラスタは、クラスタ内の個々の計算ノードに送られる数値計算配
> 分タスクのために使用される、
> (b) そのクラスタは、複数組のデータで数値計算作業を実行することで、特
> 定のタスクについて単一の機能またはシステムとして機能する(データベー
> ス、ウェブアプリケーション、ロードバランシング、ファイル サービングの
> 各クラスタを作動させるシステムは、HPCノードとみなされない)、
> (c) マネジメントまたはヘッドノードの数は、クラスタのノード総数の4 分
> の1 を超えない、
> (d) クラスタの計算ノードはすべて、同じレッドハット エンタプライズ リ
> ナックスの構成を持っている。
> HPCヘッドノード用レッドハット エンタプライズ リナックス(計算ノードの
> 管理を行うためのオプションのソフトウェアサブスクリプション)を同じク
> ラスターの計算ノード用のHPC計算ノード用レッドハット エンタプライズ リ
> ナックスのフトウェア サブスクリプションと組み合わせる場合、計算ノード
> はヘッドノードのサービスレベル契約(「SLA」)を引き継ぎます。

この制限を満たさない場合は通常のRHELのサブスクリプションをご利用ください。


次にパッケージについて
RHEL for HPC Head Node は価格づけが異なるだけの通常のRHEL Serverです。
ComputeNodeは通常のRHELより提供パッケージが非常に少ないです。
以下にHPC ComputeNodeに含まれるパッケージ 一覧がありますのでお客様の必
要なパッケージが含まれるかご確認いただけます。
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Package_Manifest/ar01s01.html#id18391134

HPCに限らずRHELの種類による違いについて以下のスライドで紹介しています。
http://www.slideshare.net/moriwaka/red-hat-enterprise-linux-17971177