環境
移行作業するシステム
Fedora release 35 (Thirty Five)
Vultr 4096.00 MB Regular Cloud Compute
移行元オブジェクトストレージ
Vultr Object Storage New Jersey
(ewr1.vultrobjects.com)
移行先オブジェクトストレージ
Vultr Object Storage Bangalore
(blr1.vultrobjects.com)
移行に用いるソフトウェア情報
rclone
rclone v1.57.0-DEV
- os/version: fedora 35 (64 bit)
- os/kernel: 6.0.12-100.fc35.x86_64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.16.11
- go/linking: dynamic
- go/tags: none
移行する理由など
Vultrオブジェクトストレージのニュージャージーリージョンの問題
あまり詳しく書くと怒られてしまいそうなのですが
Vultr Object Storage New JerseyのUptimeがとても低い状態になっています。
オブジェクトストレージのUptimeを死活監視サービスを用いて監視していますが
2023/8/9時点で直近１週間のUptimeが56%、直近３０日のUptimeが89%で、直近９０日のUptimeが96%
となっておりとても実用に耐えない状態になっていることがわかるかなと思います。
Vultrオブジェクトストレージの日本に近いリージョンが増えた
そうして私がVultrを利用し始めた頃（私が利用開始したのは:11-14-2021 11:27:16）はオブジェクトストレージに関してはNew jerseyリージョンしかありませんでしたが、
しばらくして（利用開始:08-15-2022 11:52:05）Singaporeリージョンが登場して、
さらに最近（利用開始:06-10-2023 01:39:59）ではBangaloreリージョンやその他いろいろ登場しています。
Vultrがリージョン増やしたというお知らせをしてくれるわけではないので突然増えていてびっくりするわけですが、現在（2023/08/10）では６つのリージョンのオブジェクトストレージが利用可能となっています。
Uptimeの方はというと、
シンガポールリージョンは
直近１週間で95.746%、直近３０日で98.730%、直近９０日で99.577%
となっています。
わるくはないんですが99.9%のUptimeは欲しいと思います。
ベンガルール（バンガロール）リージョンは
直近１週間で100.00%、直近３０で99.995%、直近９０日で99.939%
となっています。
Bangaloreという地名って昔はバンガロールだったらしいんですが、今はベンガルールって呼ぶのが主流らしいですね、現地での発音がそれに近いらしいです。
SLAを考えて他社と比較してみると
というのも30日で99.9%のUptimeというのは、なんとなくすごくよさそうに聞こえるんですけれども
60分 * 24時間 * 30日 * 0.001(0.1%) = 43.2分程度のダウンタイムは許容することとなります。
ちなみにあまりSLAではあり得ませんが、30日で99%のUptimeになると
24時間 * 30日 * 0.01(1%) = 7.2時間程度のダウンタイムが存在することになります。
そしてぼくはScalewayのオブジェクトストレージも利用しているのですが
そちらのポーランドリージョンのUptimeが直近９０日で100%なんです。
またGoogle Cloud Storageの方は言うまでもなく直近９０日で100%のUptimeとなっています。
そのため他者にも99.9%くらいのUptimeは十分要求していいんじゃないかなと思っているわけです。
移行準備 SSHの設定いじり
一般的にサーバー上での作業はroot以外でsudoを用いて行うべきなんでその原則でいきます。
ちなみにこの移行作業に使うマシンがサーバーである必要はないですが
移行作業には時間がかかるので常時つけていても問題ないサーバーで実行します。
ちなみに途中でSSH接続が途切れることは移行作業そのものに問題はないんですが
作業の進捗がわからなくなるのは困るので
まずはSSHが途切れないように設定します。
サーバーにSSH接続してログインできたら
sudo nano /etc/ssh/sshd_config
でエディタ（まあvimでもいいけどnanoなのです）が開いたら
ClientAliveInterval 120
ClientAliveCountMax 3
を書き込みます。すでになんらかの値が設定済みであるならばそれでいいです。
設定できましたら
sudo systemctl reload sshd
でSSHの設定ファイルを読み込み
既存のSSHウィンドウは閉じずに（SSH閉じ込め防止）
新しいウィンドウを開いてSSH接続できるか確認してください。
そんでSSH接続できたら、新しいウィンドウ側で作業します。
移行準備 移行先オブジェクトストレージのバケット作成
Vultrのアカウントにログインしてオブジェクトストレージを開く。
移行先のリージョンにオブジェクトストレージを作成してるならそれでいい。
まだ移行先のリージョンにオブジェクトストレージが作成されてないなら追加する。
ReadyになったらCreate Bucketsでバケット作成する。
このバケット名は移行元のバケット名と同じなのが一番無難です。
ただ同一リージョン内で他のユーザのものを含めユニークである（重複しない）必要がある。
移行準備 rcloneを入れる
sudo dnf install rclone
で入ります。
移行準備 rcloneの設定
rcloneのメリットはインタラクティブ（…ってあんまり言わんよね、対話形式）で設定ができることなんですが
逆に迷っちゃうので設定ファイルをいじってみたいと思います。
mkdir -p ~/.config/rclone/
nano ~/.config/rclone/rclone.conf
でエディタが開いたら
youraccesskey, yoursecretkeyは
VultrのコントロールパネルのオブジェクトストレージのAccess KeyとSecret Keyで
リージョンごとに異なる値が設定されてるので、各自の値で置き換え
もし移行元と移行先が私と異なるのであれば
endpointの値を適切に設定してください
[ewr1]
type = s3
provider = Other
access_key_id = youraccesskey
secret_access_key = yoursecretkey
endpoint = https://ewr1.vultrobjects.com
acl = public-read
[blr1]
type = s3
provider = Other
access_key_id = youraccesskey
secret_access_key = yoursecretkey
endpoint = https://blr1.vultrobjects.com
acl = public-read
って書いてあげます。
移行 Webサーバーの設定
Nginxでオブジェクトストレージをプロキシしている場合
Nginxの設定ファイルを探します
/etc/nginx/sites-available/s3.example.com
みたいな感じであるかなと思うので
sudo nano /etc/nginx/sites-available/s3.example.com
で開いて
proxy_pass https://yourbacketname.ewr1.vultrobjects.com/;
これを移行後のホスト名に書き換える必要があり
proxy_pass https://yourbacketname.blr1.vultrobjects.com/;
のようにewr1をblr1に変更します。
これはnanoの画面を開いた状態でCtrl + ¥を押下でewr1を入力してEnter、blr1を入力してEnter、Aを押下すると一括で置き換えができます。
リージョンによってエンドポイントが違うのでそこは読み替えてください。
設定できたら
sudo nginx -t
で設定ファイルに問題ないことを確認してエラーなければ
sudo systemctl reload nginx
で設定ファイルを反映します。
移行 アプリケーションの設定
たとえばMastodonなら
AWS_ACCESS_KEY_ID=youraccesskey
AWS_SECRET_ACCESS_KEY=yoursecretkey
S3_ENDPOINT=https://ewr1.vultrobjects.com
を
AWS_ACCESS_KEY_ID=youraccesskey
AWS_SECRET_ACCESS_KEY=yoursecretkey
S3_ENDPOINT=https://blr1.vultrobjects.com
のように書き換え
リージョンごとにエンドポイントだけでなくアクセスキーとシークレットキーも変わってるので注意
編集できたらアプリケーションを再起動
これ以降にアップロードされる画像は見れるようになるはずです。
移行
それでは移行していきたいと思います。
ただここでバックグラウンド処理で必要な
簡単にnohupについて説明
nohupってのはSIGHUPのシグナルハンドラを無視してくれるので
回線切断とかウィンドウ切断でSIGHUPがプロセスに送出されても
プロセスを終了せずに処理を継続してくれる
&というのはbashでコマンドの最後につけるとバックグラウンドジョブとして実行してくれる
そのためnohupと&でコマンドを括ってやるとバックグラウンドで処理を継続してもらえる
それを踏まえて以下のコマンドで移行処理を開始してください
yourbacketnameは移行元と移行先のものをそれぞれ設定してください
nohup rclone move -v ewr1:yourbacketname blr1:yourbacketname &
tail -f nohup.out
で処理の進捗状況がわかります。
この状態で特に問題なければSSHウィンドウを閉じちゃってもいいです。
あとでまたtail -f nohup.outで進捗状況を確認しにくればいいです。