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/
2013年8月26日
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
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をご購入であれば追加費用なしで利用できますのでご検討ください。
完全にオフラインで運用できるものとしては 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に由来して生成される永続的な名前のシンボリックリンクが生成されます。このファイル名は再起動により変わることはありません。
ストレージ管理ガイドに詳細が記載されておりますので参照ください。
よく見る /dev/sda1 などのデバイス名は安定していません。Linuxカーネルがデバイスを検出した順番にa,b,c,d,e... と名付けるため、デバイスの初期化順序がなんらかの理由で異なると、再起動時に異なる名前が付与される可能性があります。
RHEL5.3以降であれば、/dev/disk/by-id/ 以下に、ディスクのIDに由来して生成される永続的な名前のシンボリックリンクが生成されます。このファイル名は再起動により変わることはありません。
ストレージ管理ガイドに詳細が記載されておりますので参照ください。
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一発でいろいろできるように自動化するとかなり便利
* 教訓: 客の仕事だけでなく自分の仕事も自動化しよう
* 転ばぬ先のテストケース
* 意味: 先にテストを書いておけば防げるバグは多い。
* 教訓: サボらずテストケースを書こう。
* 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重になるのはほぼ利点がないがコストは高い。
登録:
投稿 (Atom)