Linuxのクラスタリングについて

　まず、Ｌｉｎｕｘのクラスタリングについて、分類してみる。

　ここ

第1回　多様化するクラスタ方式
http://www.atmarkit.co.jp/flinux/rensai/cluster01/cluster01.html

にＬｉｎｕｘクラスタの分類が載っている。

HA（High Availability）クラスタ
　　フェイルオーバークラスタ
　　　　共有ディスクタイプ
　　　　データミラータイプ
　　　　遠隔クラスタ
　　負荷分散クラスタ
　　　　ロードバランスクラスタ
　　　　並列データベースクラスタ
HPC（High Performance Computing）クラスタ

という分け方をしている。

まず、クラスタリングして、システムの可用性をあげるＨＡクラスタと、
並列処理して多くの計算をさせるためのクラスタ、ＨＰＣクラスタに
大きく分かれる。

---

■ＨＡクラスタ

ＨＡの場合、冗長性を上げる方法と、負荷分散する方法がある。
冗長性を挙げる方法としては、
　サービスを冗長化する方法として
　　　　Linux-HAプロジェクトの開発したHeartbeatや
　　　　Pacemakerが、
　データの冗長化として、DRBDがある。

負荷分散としては、LVS(Linux Virtual Server)などがある。

この２つ、フェイルオーバーと負荷分散を両方あわせた
オープンソースがUltra Monkeyらしい。

---

■ＨＰＣクラスタ

ＨＰＣは、OSCAR, SCore（を搭載した巫女GNYO/Linux）,openMosix,Rocks Clusters などがあるみたい。

---

流れ的には、LinuxにＧＰＧＰＵを載せて、CUDA使ってガンガン並列計算させるっていう話が、多くなってくるんじゃないかと思う。
　シュミレーション利用としてね・・・

サマータイムなどの節電対策によっては、運用次第で最大電力需要をかえって引き上げ！！

ここのサイト

夏季における計画停電の影響と空調節電対策の効果を評価
http://www.aist.go.jp/aist_j/new_research/nr20110621/nr20110621.html


によると（以下斜体は上記サイトより引用）


　独立行政法人 産業技術総合研究所【理事長 野間口 有】（以下「産総研」という）安全科学研究部門【研究部門長 四元 弘毅】社会とLCA研究グループ 井原 智彦 研究員、素材エネルギー研究グループ 玄地 裕 研究グループ長らは、夏季の計画停電やエアコンを中心とした各種の節電対策が、最大電力需要や室内温度などに与える影響・効果を定量化した。


その結果


3時間ずつの輪番停電を実施しても、戸建住宅の屋内温度は35 ℃超となり、業務と家庭の合計では9%の最大電力需要の削減にとどまることがわかった。


３５度・・・たえられません。
計画停電はありえません。
どうも、停電が終わった後、一気にエアコンをつけるかららしい。


サマータイムなどの節電対策によっては、運用次第で最大電力需要をかえって引き上げてしまう可能性があることも示唆された。


サマータイムを呼びかけた、民主党は（－＿－；）・・・


この評価の詳細は、2011年7月22～24日に茨城県つくば市で開催される「第6回日本ヒートアイランド学会大会」で発表される。


いや、こんな大事なことは、ＮＨＫの「ＮＨＫスペシャル」か「サイエンスＺＥＲＯ」でやってくれ（＾＾；）

WBSの作り方

といっても、ワールドビジネスサテライトとは何の関係もありません。
トレンドたまごの話です。違！、Work Breakdown StructureのＷＢＳの話。
見てて、あまりにも気になったので・・・

---

■ＷＢＳの詳細化の２つの方法

ＷＢＳは、ツリー上（あるいは表形式）で、仕事をブレークダウンしていくわけだけど、
（字のまんまや＾＾；）その分割の仕方には、大きく２とおりあります。

　　・成果物によるわけかた
　　・作業にやるわけ方

　成果物によるわけかたは、
　　　　　「要求仕様書」、
　　　　　　　はじめに
　　　　　　　全体説明
　　　　　　　機能要件
　　　　　　　非機能要件
　　　　　　　制約等
　　　　　　　資料その他
　　　　　「外部設計書」、
　　　　　「詳細仕様書」
　　　　　「プログラム」
　　　　　「テスト仕様書」
　のように、成果物を挙げていき、さらに、「要求仕様書」の中を、その章立てに分けていき・・・・という手順で詳細化していく。


　作業の場合は、
　　　「ユースケースを作成する」
　　　　　　アクターを出す
　　　　　　ヒアリングする人を決める
　　　　　　ヒアリングする
　　　　　　　　　ヒアリングの日程を決定する
　　　　　　　　　ヒアリングを行う
　　　　　　ユースケースシナリオを作成する
　　　　　　ユースケース図を作成する
　のように、作業を羅列して、詳細化していく。


　気になったのは、作業に分けた場合の話。

---

■ＷＢＳの詳細化のルール

ここで、ＷＢＳには、詳細化する場合にルールがある。


WBSには、守るべき3つのルールがある
http://www.atmarkit.co.jp/im/cpm/serial/wbs/02/01.html


に書かれている、１００％ルールというもの。

これは、網羅性とかいうやつで、

子の要素を全部足したら、親の要素にならないといけない
（漏れがあってはいけない）
というもの。

---

■作業の網羅性と成果物の網羅性

作業の網羅性を確認する場合

　　その作業を行う前に、入力がすべてそろっているか？
　　その作業を行った後に、成果物が作成されるか？

というのを確認（同レベルでの、事前・事後条件チェック）した後で、

　手順どおりに行うと、入力値を元に、親要素で期待される成果物が
作成できるか？

というのを確認（詳細化チェック）をするんだけど、
気になったモノは、詳細化された要素を足しても、親の要素にならないし、
親の要素に対して、子の要素は必要か？？と思ってしまったから。

　実は、作業の網羅性を行うのは、かなり難しい。

　成果物の網羅性は実は簡単で、そのドキュメント→章立て→項立て
と分解していけばいいので。

---

■ＷＢＳの書き方

　といっても、成果物がいっぱいのときがある。このとき、成果物を羅列すると、
わけわからなくなる。

　そこで、組織とか、構造とか、場合によっては、工程・フェーズなどによって、
荒く分類しておくことがある。

　たとえば、

ＥＴＬシステム
　　会計システム改修
　　販売システム改修
　　生産システム改修
　　データ連携システム

と分かれていて、それぞれにドキュメントがある場合（とくに章立てとか内部が違う場合）は

ＥＴＬシステム
　　会計システム改修
　　　　　「要求仕様書」、
　　　　　「外部設計書」、
　　　　　「詳細仕様書」
　　　　　「プログラム」
　　　　　「テスト仕様書」
　　販売システム改修
　　　　　「要求仕様書」、
　　　　　「外部設計書」、
　　　　　「詳細仕様書」
　　　　　「プログラム」
　　　　　「テスト仕様書」
　　生産システム改修
　　　　　「要求仕様書」、
　　　　　「外部設計書」、
　　　　　「詳細仕様書」
　　　　　「プログラム」
　　　　　「テスト仕様書」
　　データ連携システム
　　　　　「要求仕様書」、
　　　　　「外部設計書」、
　　　　　「詳細仕様書」
　　　　　「プログラム」
　　　　　「テスト仕様書」

と分けてしまったほうがいい。

---

■つまり・・・

網羅性を高めるには

　　・組織・構造・工程・フェーズ等
　　・成果物
　　・作業

によって分けたほうがいいということになる。

これと、ゴール指向なんかとの関係については、別に書く。