こんなサービスがあった。
元々仮想通貨採掘とか、自宅リソースを何か外部の人に使って貰うとかそういうのをあんまりやってないのですが、ちょっと面白い観点で自宅リソースの一部を供出することで外の人に貢献するというサービスがありました。STORJと言うそうです。
これはストレージ貸なんだそうで、ただSLA的な条件があり、1ヶ月あたり5時間以内の停止に停止時間を納める必要があるようです。あとは、月間2TBトラフィックが発生することがある、最低100Mbpsの帯域は供給できるようにする必要がある・・等のような感じで、実に様々な条件はありますが、そこはトークン授与の画面を見て貰えれば分かるんじゃないかなと。
なお、そのストレージ貸をする事で得られるものとして、仮想通貨：Storj が供出帯域・容量に従い、支払われるそうです。2020年3月20日時点で確か1Storj = 0.09ドルだったかと思います。ただ、過去の私のブログを見れば分かると思うんですが、金儲け系のことには余り興味を示さない人間なので、このブログではどの程度儲かるものなのか？とか金銭絡みの話はしません。
単純にこのStorjの取り組みに興味を持ったので、どんなことが行われるのか、どんな負荷がかかるのか、そこに視点を置いて書くのみです。
やってみることにした
仮想通貨採掘とかでは、GPUとかCPUをガンガン回す代物が多く、我家の環境では動かすことそれ自体が全体に対してデメリットを与える可能性が懸念されました。さて、このサーバは外部からがっつりアクセスされるサーバとなるため、ネットワーク周りからの見直しが必要になりました。
ネットワークの構成
新たなDMZセグメントを設営し、そこにサーバをぶら下げることにしました。
外部から実サーバへのアクセスにおいては、途中経路にあるSophos UTM9によってDNATを構成し、単純にポートフォワードしつつも通信内容はIPSで監視・不正アクセス遮断をするようにしました。
当然のことですが、DMZ帯から内部サーバへのアクセスは監視用ソフトウェアやNTPアクセスに留め、それ以外の通信はNGにしています。
サーバ構成
サーバの構成は上図の通りとしました。Linux-CLI版を使用する場合、その動作はDocker上のコンテナにて行う仕様でして、DockerイメージはDockerhubにて公開されているようです。
今回私の環境ではシングルのSSDが700GBほど、RAID5構成のNL-SAS HDDが1TB程余っていたので、それぞれを500GBずつ供給してStorjコンテナを動かすことにしました。
組み立て
前提
以下前提は是非己で調べてください。本記事では述べません。
- Storjサイトにて「Become a Host」をクリックして自身の認証トークンをゲットする
- https://www.myetherwallet.com/ へアクセスし、ウォレットを作成する。ここで得られる「アドレス」が必要になる
- サーバを用意する。なお、当方はUbuntu 18.04 LTSを使用している。
- 提供するディスクをフォーマット＆マウントして、パス指定が出来る状態にしておく。ファイルシステムは何でも良さそうだけど、取り敢えずXFSにしておいた。
Docker環境の構築
今回、OSバンドルのDockerではなく、Docker-ceを使います。
apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
apt-key fingerprint 0EBFCD88
pub rsa4096 2017-02-22 [SCEA]
9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid [ unknown] Docker Release (CE deb) <docker@docker.com>
sub rsa4096 2017-02-22 [S]
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
apt-get update
Docker-CEのインストール
Dockerと関連コンポーネントのインストールを行います。最後、一旦再起動をします。
apt-get install docker-ce docker-ce-cli containerd.io
docker run hello-world
-> サンプルスクリプトが実行され、終了したことを確認する
shutdown -r now
Identityの導入
同じくStorj Labsが提供しているIdentityと言うソフトウェアを拾っています。
このソフトウェアにより、Storjより払い出された認証トークンとの紐付けを行います。
■Identityソフトウェアの導入
curl -L https://github.com/storj/storj/releases/latest/download/identity_linux_amd64.zip -o identity_linux_amd64.zip
unzip -o identity_linux_amd64.zip
chmod +x identity
sudo mv identity /usr/local/bin/identity
■ストレージノードアカウントの作成(めちゃ時間かかる)
identity create storagenode
■アカウント情報に認証トークンを組み込む
identity authorize storagenode username@bluecore.net:1********************....***2
なお、上記にも記載していますが、アカウントの作成処理は最も時間がかかります。
どうやら暗号化キーを所定の強度を満たすまで延々と作らせる処理が走るようなのですが、その暗号強度がなかなか求められる値まで到達しない・・・・と言うもので長期化しがちなようです。
我家の環境では、その時E5-2420（SandyBridge-EN)を使用していましたが、12コアフル回転させて3時間経過したところで作成処理が完了していました。鍵の総数は5-6億個ぐらいだったようです。
逆にそこがうまくいけば後はだいぶお手軽に組めます。
Dockerイメージの起動
それぞれのDockerコンテナを起動します。
■Dockerコンテナを起動(SATA側)
docker run -d --restart unless-stopped -p xxxxx:28967 \
-p 127.0.0.1:14002:14002 \
-e WALLET="0x0*********************************9" \
-e EMAIL="username@bluecore.net" \
-e ADDRESS="******.bluecore.net:xxxxx" \
-e STORAGE="500GB" \
--mount type=bind,source="/home/username/.local/share/storj/identity/storagenode",destination=/app/identity \
--mount type=bind,source="/data/disk1",destination=/app/config \
--name storagenode storjlabs/storagenode:beta
■Dockerコンテナを起動(SSD側)
docker run -d --restart unless-stopped -p xxxxx:28967 \
-p 127.0.0.1:14012:14002 \
-e WALLET="0x0*********************************9" \
-e EMAIL="username@bluecore.net" \
-e ADDRESS="******.bluecore.net:xxxxx" \
-e STORAGE="500GB" \
--mount type=bind,source="/home/username/.local/share/storj/identity/storagenode",destination=/app/identity \
--mount type=bind,source="/data/disk2",destination=/app/config \
--name storagenode-2 storjlabs/storagenode:beta
以下のように起動確認をします。
Status列にあるように「Up」となっていれば大体は起動に成功していると思います。
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
************ storjlabs/storagenode:beta "/entrypoint" 8 minutes ago Up 8 minutes 127.0.0.1:14012->14002/tcp, 0.0.0.0:2xxxx->28967/tcp storagenode-2
************ storjlabs/storagenode:beta "/entrypoint" 3 hours ago Up 3 hours 127.0.0.1:14002->14002/tcp, 0.0.0.0:2xxxx->28967/tcp storagenode
また、該当のディレクトリを彫ってみるとこんな風になっていました。中に暗号化されたデータがオブジェクトストレージ的な配置の仕方で置かれているのかなぁ？と言う風に見えました。
root@storj:/data/disk1# ls -al
total 44
drwxr-xr-x 3 root root 86 Mar 21 22:38 .
drwxr-xr-x 4 root root 4096 Mar 21 12:39 ..
-rw------- 1 root root 7196 Mar 21 21:58 config.yaml
-rw------- 1 root root 32768 Mar 21 22:38 revocations.db
drwx------ 6 root root 4096 Mar 21 22:00 storage
-rw------- 1 root root 1202 Mar 21 22:38 trust-cache.json
root@storj:/data/disk2# ls -al
total 44
drwxr-xr-x 3 root root 86 Mar 22 01:47 .
drwxr-xr-x 4 root root 4096 Mar 21 12:39 ..
-rw------- 1 root root 7196 Mar 22 01:47 config.yaml
-rw------- 1 root root 32768 Mar 22 01:47 revocations.db
drwx------ 6 root root 4096 Mar 22 01:47 storage
-rw------- 1 root root 1202 Mar 22 01:47 trust-cache.json
ファイルとしてどんなものが入ってるのかも確認してみましたが、どうやらこいつはblobストレージとして動いているようです。blogディレクトリに大量のオブジェクトが配置されていました。
かかる負荷はどの程度だろうか
取り敢えず半日程度動かした後の状態を確認してみましたがこんな感じです。
HDD領域を使用 
SSD領域を使用
取り敢えずじわじわっと使われているようです。このStorjはユーザリクエストの振り裁きを行うサーバがあり、これを「サテライト」と呼んでいます。このサテライトが世界全体で数個存在しており、そこが引き受けたリクエストの送り先として私の環境にあるStorageNodeへアクセスしたり、データを持って行ったり回収したりするようです。
なんか足下見られてる感満載というか、何故でしょうかね、HDD層よりもSSD層の方が優先していつ買われているようです。応答速度が速いからかな？と思うのですが、HDD側もそれなりのライトキャッシュを備えたディスクなんだけどなーとか。
では、CPUとかメモリとか、実際の基盤にはどういう負荷がかかってるんでしょーか。
見ると分かるのですが、それほど過剰な負荷はかかっていません。
ネットワーク帯域の状況について、Mbps単位で見れるZABBIXのグラフを参照してみたけど、こんな感じになっている。
まだ使用量が少ないからなのか、あるいはこういうものなのかは何とも判別できませんが、長期的に動かせばそれなりに特異的な傾向も見つかるのではないかと期待しつつ、暫く動かしてみようかなと思っています。
using WordPress and
Comments are closed