Vultrオブジェクトストレージのリージョン移動

## 環境
移行作業するシステム
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接続してログインできたら

```bash
sudo nano /etc/ssh/sshd_config
```
でエディタ（まあ`vim`でもいいけど`nano`なのです）が開いたら
```bash:/etc/ssh/sshd_config
ClientAliveInterval 120
ClientAliveCountMax 3
```
を書き込みます。すでになんらかの値が設定済みであるならばそれでいいです。

設定できましたら
```bash
sudo systemctl reload sshd
```
でSSHの設定ファイルを読み込み
既存のSSHウィンドウは閉じずに（SSH閉じ込め防止）
新しいウィンドウを開いてSSH接続できるか確認してください。
そんでSSH接続できたら、新しいウィンドウ側で作業します。

## 移行準備 移行先オブジェクトストレージのバケット作成
Vultrのアカウントにログインしてオブジェクトストレージを開く。
移行先のリージョンにオブジェクトストレージを作成してるならそれでいい。
まだ移行先のリージョンにオブジェクトストレージが作成されてないなら追加する。
ReadyになったらCreate Bucketsでバケット作成する。
このバケット名は移行元のバケット名と同じなのが一番無難です。
ただ同一リージョン内で他のユーザのものを含めユニークである（重複しない）必要がある。

## 移行準備 rcloneを入れる

```bash
sudo dnf install rclone
```
で入ります。

## 移行準備 rcloneの設定

rcloneのメリットはインタラクティブ（…ってあんまり言わんよね、対話形式）で設定ができることなんですが
逆に迷っちゃうので設定ファイルをいじってみたいと思います。

```bash
mkdir -p ~/.config/rclone/
nano ~/.config/rclone/rclone.conf
```

でエディタが開いたら
`youraccesskey`, `yoursecretkey`は
VultrのコントロールパネルのオブジェクトストレージのAccess KeyとSecret Keyで
リージョンごとに異なる値が設定されてるので、各自の値で置き換え
もし移行元と移行先が私と異なるのであれば
endpointの値を適切に設定してください

```bash:~/.config/rclone/rclone.conf
[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
```

で開いて

```nginx:/etc/nginx/sites-available/s3.example.com
proxy_pass https://yourbacketname.ewr1.vultrobjects.com/;
```
これを移行後のホスト名に書き換える必要があり
```nginx:/etc/nginx/sites-available/s3.example.com
proxy_pass https://yourbacketname.blr1.vultrobjects.com/;
```
のように`ewr1`を`blr1`に変更します。
これは`nano`の画面を開いた状態で`Ctrl` + `¥`を押下で`ewr1`を入力してEnter、`blr1`を入力してEnter、`A`を押下すると一括で置き換えができます。
リージョンによってエンドポイントが違うのでそこは読み替えてください。
設定できたら
```bash
sudo nginx -t
```
で設定ファイルに問題ないことを確認してエラーなければ
```bash
sudo systemctl reload nginx
```
で設定ファイルを反映します。

## 移行 アプリケーションの設定

たとえばMastodonなら
```bash:/home/mastodon/live/.env.production
AWS_ACCESS_KEY_ID=youraccesskey
AWS_SECRET_ACCESS_KEY=yoursecretkey
S3_ENDPOINT=https://ewr1.vultrobjects.com
```
を
```bash:/home/mastodon/live/.env.production
AWS_ACCESS_KEY_ID=youraccesskey
AWS_SECRET_ACCESS_KEY=yoursecretkey
S3_ENDPOINT=https://blr1.vultrobjects.com
```
のように書き換え
リージョンごとにエンドポイントだけでなくアクセスキーとシークレットキーも変わってるので注意
編集できたらアプリケーションを再起動
これ以降にアップロードされる画像は見れるようになるはずです。

## 移行

それでは移行していきたいと思います。

ただここでバックグラウンド処理で必要な
簡単に`nohup`について説明
`nohup`ってのはSIGHUPのシグナルハンドラを無視してくれるので
回線切断とかウィンドウ切断でSIGHUPがプロセスに送出されても
プロセスを終了せずに処理を継続してくれる
`&`というのはbashでコマンドの最後につけるとバックグラウンドジョブとして実行してくれる
そのため`nohup`と`&`でコマンドを括ってやるとバックグラウンドで処理を継続してもらえる

それを踏まえて以下のコマンドで移行処理を開始してください
`yourbacketname`は移行元と移行先のものをそれぞれ設定してください

```bash
nohup rclone move -v ewr1:yourbacketname blr1:yourbacketname &
```

```bash
tail -f nohup.out
```
で処理の進捗状況がわかります。
この状態で特に問題なければSSHウィンドウを閉じちゃってもいいです。
あとでまた`tail -f nohup.out`で進捗状況を確認しにくればいいです。