[ubuntu-jp:6492] Re: Ubuntu Serverを使ったグリッドコンピューティングの定番手法

2021年 11月 4日 (木) 11:28:03 UTC

高橋秀羅 a.k.a まんじゅ（´ん｀）です。

亀レスというべきか、スレッドの掘り返しお許しください。


> でもこれ、負荷分散ではなくて安定化なんですよね。

まあまあ。私個人は楽しく夢想しております。

私の中の頭で「各言葉（固有名詞含む）の関連性」を整理する限りでは；

* 『オンプレミス』と『ベアメタル』が同じ意味と捉える。
*
『Kubernetes』は確かにクラウドサービス向け、特に『Docker』と強結合な印象が強いが、複数マシンのオーケストレーションができるのだから『ベアメタル』も行けるのでは？
* ましてやJuju/MAASは「『ベアメタル』まで」と謳っているのにあまり話題を聞かないのは、それだけKubernetesで用が足りてるからでは？

という愚察をした限りですが、それっぽいものがありました。手前味噌ですがQiitaでそれについて記されている記事を：
https://qiita.com/kkohtaka/items/d307dc664907209fbb51

曰く；
> 1. matchbox をセットアップする
> 2.  Typhoon から提供されている Terraform モジュールに必要な設定を記述する
> 3. その Terraform モジュールを利用して bootkube を実行する

との事で別途『matchbox（ https://matchbox.psdn.io/ ）』のセットアップして……あれ？

やっぱり『オンプレミス』ないし『ベアメタル』といった「複数台の物理端末の起動含めた制御」となると、『Juju（ https://juju.is/
）』と『MAAS（ https://maas.io/ ）』の組合せが簡単なような……？

--------

さて、『ownCloud』のオーケストレーション・オペレーションについてですが、

> 40GBくらいのデータの同期を複数クライアントから行っている最中にMySQLが落ちました。

の後の対処内容の通り「メモリ不足」が原因とは存じます。

この後の話に関しては、
「でもせっかく『分散コンピューティング』するならさ……！」
という妄想かつ『ownCloud』の仕様も把握せず、自分はそこまで入り浸っていない上での世迷い言ですが；


MySQLの親戚は『MariaDB』のドキュメントですが、興味深い公式ドキュメントがありました。『正しいストレージエンジンの選択』：
https://mariadb.com/kb/ja/choosing-the-right-storage-engine/

「そこまで沼に入水したくない」
という事であれば、無難にHTTPサーバーのスケールイン・アウトをオーケストレーションするのが良いのかな（よく見る構成だし。ただし自分が実際に手を動かしてやった事は無い）？
という憶測は建ちます。

----------

「物理的に分離しているプロセッサ・メモリを同一のものと見なして演算を実行させる」
という事そのものが私個人も未開拓の領域の為、有識者の皆様はもとより小池さんからも、
「何いってんだこいつ？」
とあしらわれる覚悟はできております。

ですが私個人のわがままで恐縮ですが、皆様の知見を共有して頂ける機会になればと思い、返信させて頂きます。


高橋秀羅 Hidetsugu TAKAHASHI

2021年9月19日(日) 16:09 Toshiaki Koike <t-k ＠ dive2.blue>:

> # Q.
>
> 『MicroK8sのクラスターを作って、自宅サーバの負荷分散』が、本当に負荷分散に繋がるのでしょうか？
>
>
> 自分の場合は、ownCloudサーバの運用でして。
>
> ownCloudサーバをVPSから自宅サーバに移行したのですが、その際のサーバのスペックがメモリ4GBだったこともあり、40GBくらいのデータの同期を複数クライアントから行っている最中にMySQLが落ちました。
> その後、メモリを16GBにしてから落ちることはなくなったのですが、それでも高負荷対策をしたいなと。
> Kubernetesのサービス（pod）を複数起動させておいて、落ちたら別のpodが起動するようになっていれば落ちなくなると。
> でもこれ、負荷分散ではなくて安定化なんですよね。
>
> なおグリッド・コンピューティングについてもう少し調べていたところ、ミドルウェアのSun Grid
> Engineはサンがオラクルに買収された後、オープンソースコミュニティで、Son of Grid Engineと、Open Grid
> Schedulerに派生したものの、現在は両方とも開発が止まってる。
>
> デファクトのGlobusツールキットは2018年1月で開発終了、SCoreは現在でもPCクラスタコンソーシアムに引き継がれているものの、情報がほぼない。
>
>
> 2021-09-19 (日) の 15:40 +0900 に TAKAHASHI Hidetsugu さんは書きました:
>
> 高橋秀羅 a.k.a まんじゅ（´ん｀）です。
>
>
> とても興味のある話題なのでレスをさせて頂きます。
>
> しかし、まず無知による愚問をさせて下さい:
>
>
> # Q.
>
> 『MicroK8sのクラスターを作って、自宅サーバの負荷分散』が、本当に負荷分散に繋がるのでしょうか？
>
>
> ## 私個人の案(できるだけ簡潔に)
>
>
> * せっかくUbuntu Serverを用いているので、Canonical社の『Juju /
>
> MAAS』を使ってはどうだろう。
>
>      * ベアメタル向けの操作もある
>
>      * 『Juju /
>
> MAAS』自体で『Kubernetes』の『Charm』,『Bundle』が提供されている記憶
>
> * 『遠隔手続き呼び出し(RPC』で調べていくのも一つかも
>
>
> ## tl; dr(整理も至らぬまま書いた長い持論展開)
>
>
> 私個人整理できてない状態でこの文面を書いてしまっていますので、
>
> 「単語から連想した自分の知見への関連付け」
>
> を行っているという点をご容赦頂きながら読んで頂けると幸いです:
>
>
> ----------
>
>
> 「そもそもUbuntu
>
> Serverで、複数のサーバを使った並列処理、分散コンピューティングの手法があるのでは？」
>
> ここで私個人躓いてしまったのが、
>
> 「『分散コンピューティング』の定義ってなんだべ？」
>
> と思い抱きました。また;
>
>
> ・Kubernetesはクラウドサービス向けの技術なのでオンプレミスでの利用のための情報が少ない
>
> ・そもそもオンプレミスなら使えるリソースはフルに使い切っていいので、Kubernetesだとムダがある
>
> という考えに私個人も同感を抱きました。
>
>
> そこで、手前味噌にWikipedia日本語版で『分散コンピューティング』について引きました:
>
>
> 分散コンピューティングは、コンピュータ同士をネットワーク接続し、効率的に通信できるよう努力した結果として自然に生まれた。しかし、分散コンピューティングはコンピュータネットワーク
>
> <
>
> https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF>と同義ではない。単にコンピュータネットワークと言った場合、複数のコンピュータが互いにやり取りするが、単一のプログラムの処理を共有することはない。World
>
>
> <https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%3Eと同義ではない。単にコンピュータネットワークと言った場合、複数のコンピュータが互いにやり取りするが、単一のプログラムの処理を共有することはない。World>
>
>  Wide Web <
>
> https://ja.wikipedia.org/wiki/World_Wide_Web
>
> >
>
> はコンピュータネットワークの例であるが、分散コンピューティングの例ではない。
>
>
>
> 分散処理を構築するための様々な技術や標準が存在し、一部はその目的に特化して設計されている。例えば、遠隔手続き呼出し
>
> <
>
> https://ja.wikipedia.org/wiki/%E9%81%A0%E9%9A%94%E6%89%8B%E7%B6%9A%E3%81%8D%E5%91%BC%E5%87%BA%E3%81%97
>
> >
>
> (RPC)、Java Remote Method Invocation
>
> <
>
> https://ja.wikipedia.org/wiki/Java_Remote_Method_Invocation
>
> > (Java
>
> RMI)、.NET Remoting <
>
> https://ja.wikipedia.org/wiki/.NET_Remoting
>
> >
>
> などがある。
>
>
> *Wikipedia日本語版『分散コンピューティング』の項より抜粋*
>
>
> たまたま自分が直近の開発仕事で『gRPC
>
> [1]』が絡んだ技術調査を調べていた事もあり、つい、
>
> 「(実装する。もしくはこれらを用いた実装があるだろう。という前提で持論を展開してしまっているが)
>
> 『gRPC』と『Protocol Buffer
>
> [2]』を用いれば、数年前よりは容易に実装が可能なのでは？
>
> そしてとっくにされているのでは？」
>
> と思い至った次第です。
>
>
> ------
>
>
> と、つい熱を込めてポエム(詩じゃない何か)をのたまいてしまいましたが、『RPC』特に『gRPC』の方向で調べ直すのは徒労になりかねないので;
>
>
> 自宅サーバの負荷分散をしよう
>
> に着目し、
>
> 「複数のワンボードコンピュータによるスケール・イン/アウトを動的に行えれば良い」
>
> のであれば、
>
> 「『Juju/MAAS』を触るのが無難な選択」
>
> かと思った次第です。
>
>
> 乱文・長文お許し下さい。
>
> 小池さんの今後の調査の方向を広げられる一因になればとても幸いです。
>
>
>
> # 脚注
>
>
> [1] 『Google』が提唱し、『Cloud Native Computing
>
> Foundation』が主導して開発しているRPCフレームワーク:
>
> https://grpc.io/
>
>
>
> [2]
>
> 『Google』が提唱した「汎用構造定義フォーマット」(という高橋の認識)。『gRPC』でも用いられている:
>
> https://developers.google.com/protocol-buffers
>
>
>
>
> On 2021/09/19 11:59, Toshiaki Koike wrote:
>
> 小池です。
>
> 昨年Raspberry
>
> PIを3台購入して、MicroK8sのクラスターを作って、自宅サーバの負荷分散をしようと勉強している（時間がとれず中途半端に終わってる）のですが、よくよく考えてみると
>
>
> ・Kubernetesはクラウドサービス向けの技術なのでオンプレミスでの利用のための情報が少ない
>
> ・そもそもオンプレミスなら使えるリソースはフルに使い切っていいので、Kubernetesだとムダがある
>
>
> ことに思い当たり「そもそもUbuntu
>
> Serverで、複数のサーバを使った並列処理、分散コンピューティングの手法があるのでは？」と思い調べてみたのですが、グリッドコンピューティングに関連してかなり古い記事ばかりでした。
>
> 一番新しそうなもので、2008年。
>
> https://mizuno.hatenadiary.org/entry/20080809/1218289825
>
>  <
>
> https://mizuno.hatenadiary.org/entry/20080809/1218289825
>
> >
>
> （Ubuntu Japanese Teamの水野さんの記事ですよね）
>
>
> wikipediaによればLinuxのグリッドコンピューティングにはBeowulfって方式があるらしいですが、これも情報が少ない。
>
>
> 現在は、Linuxでのグリッドコンピューティング手法は死滅してしまったのでしょうか？
>
> それともクラウド技術に圧されて流行ってないから情報が少ないだけで、実現のためのパッケージがUbuntu
>
> Serverに用意されてたりするのでしょうか？
>
>
> --
>
> -------------------------------------------------
>
> 小池利明
>
> t-k ＠ dive2.blue
>
>  <mailto:
>
> t-k ＠ dive2.blue
>
> >
>
> Toshiaki Koike
>
> -------------------------------------------------
>
>
> --
>
> -------------------------------------------------
> 小池利明
> t-k ＠ dive2.blue
> Toshiaki Koike
> -------------------------------------------------
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <https://lists.ubuntu.com/archives/ubuntu-jp/attachments/20211104/c5b3db08/attachment.html>