# クラスタ間でのリソース借用貸与システム

## 概要


## 進捗管理

### 10/13

#### やったこと

- gRPCのお勉強
- gRPCでサーバを立てた
- サーバ立ったけど動作確認はまだ
- 来週は双方向非同期通信までできるようにしたいね

### 10/20

#### やったこと

- gRPCでサーバ クライアント間通信
- Req-Resのタイプ
- 非同期双方向のタイプ

#### 考えたこと

- ネゴシエーションをするときに相手との間でどっちがサーバになるかを決めないといけない
- ~~でもこれって２つのときにしか発生しない問題かもしれない~~
- ~~そんなことないかも~~
- どっちがサーバになるか決める必要がありますね
- 各クラスタの借用貸与モジュールが特定のポートで待ち受けしてそこにデータを各自送りつける方式でもいい
- ↑が良さそうかも
- 既にコネクションを貼っている場合（相手がクライアントとして接続している場合）は新規接続をしないで、既存のコネクションで通信すればいい屋根
- これ、グローバルで値を持つ必要があってめんどいかも

### 11/10

#### 意見交換会

- テストベッド間でのリソースの融通
- リソースの種類とか量とかが違う
- ハードウェアの仕組みが違う
- 共通の仕組みとか言語が違うのでそれらを変換する
- deterlabとstarbed間で同じようなことしてる
- 出せるもの出せないものの成約をどうやって記述するか
- 別れている意味がなくなるかも
- この研究をやる意義とか意味とか
- 異種性とか
- 権利権限の設定
- コマンドの扱い
- できることできないことが所によって違う
- できることによってリソースの割り当てを変えるのは難しい
- 適切な割り当てが難しい
- 難しいところを明確にしてどうやって解決するかを示す
- 今回作るのはこれでいい
- 人間が勝手にいろいろ設定していい
- リソースの定義がクラスタ間で違う
- DBのレプリケーションすれば借用モジュールは予約だけすればいい
- 全体で同じデータを持つ
- 前提の条件・制約の設定からその解決法
- これやらないと意味とか意義とかがわからなくなる
- 落とし所をどこにするか
- 作った上で制約を作るのもあり
- 各クラスタは異質なものがいい
- 同じもの複数だと最悪手動でいい
- バッチを想定
- バッチが終わればリソースは開放
- バッチをより早く、より高密度でやる
- ハイパフォーマンス寄りになってくるかも
- deterlabはこれ
- starbedは違うのでうまく行かない
- シミュレーションでできるかも

####