
リソース・マネージャー同士で一定の範囲(Kind)を決めて、非同期で更新。メッセージパッシングするような形で、次のリソース・マネージャーが更新処理を行う
2010-01-10 16:57:40
分散ロックサービスのChubbyを見ると、分散合意問題を非同期的に解決するのは Paxos プロトコルとあって、TCMPプロトコルも信頼性の確保でACK(応答確認)=メッセージパッシングと解釈する説 http://bit.ly/7Bu4pU
2010-01-10 16:58:03
信頼性の確保でACK(応答確認)=メッセージパッシング このあたりとか → ロック・サービスは結果を告知するメカニズムのサポートに適している
2010-01-10 16:58:44
そんなことしたら完全にカオスになると思うのですが、「サービス開発者に連続的なプログラミングを幻想を提供する」ってこのことかと思ったり
2010-01-10 16:59:16
これってどういう意味かな(・∀・)? → 粒度の細かい (fine-grained) ロックではなく、粒度の粗い (coarse-graind) ロックのみを提供する
2010-01-10 16:59:46
ネットワークのネットワークであるインターネットを、実証済みである最強の分散コンピューティング環境として模倣したのかな?
2010-01-10 17:01:15
そのロックの対象となる粒度(Kind)の数 = 分散ハッシュテーブルにおけるサーバーの数と同じにならないだろうか?
2010-01-10 17:01:58
この場合、データの整合性が一番問題とされるわけですが、それをどのように確保するかは、首藤先生がクラウドの技術の中で言及していて
2010-01-10 17:02:08
データの整合性を完全に防ぐには、サーバー一覧表をひとつだけにしてしまう(全クライアントから単一中継サーバーを使う)か、すべてのサーバー一覧表の間で、一貫性を保つ必要がある。
2010-01-10 17:02:25
どちらにせよ、性能上極めて不利であるか、現実的ではない。この点、完全な一貫性よりは条件を緩めて、一時的、過渡的な不整合は許容するという方針、つまりはACIDの代わりにBASEに従わざるを得ない。
2010-01-10 17:02:37
分散したサーバー一覧表の間で、これらの一貫性を保とうとするから大変になるのであって、ここでも一貫性の条件を緩める必要がある。つまり、問い合わせの「サーバー間での転送」を許すのである
2010-01-10 17:03:13
そのサーバー間での転送を実現し、かつ末端のサーバーにまで情報がいきわたるような技術が既にあって、それがP2Pにおける分散ハッシュテーブルである、だそうです。
2010-01-10 17:03:34
ルーティング用語の世界では、サーバー一覧表=経路表、一覧表の維持管理=ルーティング、転送=フォワーディングが、相当する
2010-01-10 17:03:53
このときに用いられる現時点で考えられるアルゴリズムでは、一台当たりの経路表のサイズも「O(log N)」まで抑えらている。ID空間の大きさが2の160乗の場合、どんなにサーバー台数が増えてもフィンガーテーブルが持つエントリ数はたかだが160である。
2010-01-10 17:04:02
その結果、サーバー間での一貫性の確保による維持コストは台数に比例し、これら「転送」によってネットワークの負荷が高まるわけですが、担当ノードに「直接到達させる」という方法によって、この問題を解決することができ、これを首藤先生は”「転送なし」の構造化オーバーレイ”と呼んでいます。
2010-01-10 17:04:14
つまり、これはグローバルトランザクションの「一貫性の確保」という観点にも、BASE思考を用いることで解決できるのではないかということなんだけど、どうでしょう(・∀・)?
2010-01-10 17:04:30
ちなみに、12月のスティルハウスの書庫 Paxosお勉強メモ エントリーはこちら http://bit.ly/4VBxTk
2010-01-10 17:04:42
簡略化されたPaxos 故障を許容する形で分散コンピュータシステムを運用するフォールトトレラントな簡略化アルゴリズム http://bit.ly/7DV8Tu
2010-01-10 17:05:03