初めに
こんにちは！新米エンジニアのゆいちゃです！
もう2022年も後わずか。入社して早9カ月。
エンジニアの皆さんは社会人1年目のことを覚えていますか？
振り返ってみれば、技術的にも学ぶべきことが多く、充実した一年だったなと思います。
さて、今回ご紹介する内容はGCPのVeeamアプライアンスで自動デプロイされる「worker」についてです。
それでは参りましょう！
workerとは？
GCEのバックアップやリストアを取得する際に、補助的な役割として自動でデプロイされるサーバのことです。 ちなみに、workerをデプロイするVPCやサブネットは指定することができます。 下の図では、同一VPCで表現しています。
このworkerの性能については「プロファイル」設定で変更することができますが、何も設定していなければデフォルトの「e2-highcpu-8」でデプロイされます。
しかし、このworkerを1台立てるためには4TBの標準永続ディスクを接続した状態でデプロイされるため、GCP上で「Persistent Disk Standard」の割り当て上限を4TB引き上げる必要があります。つまり、GCE2台を同時でバックアップを取得しようとすると、標準永続ディスク8TBの空きが必要になってきます。
4TBの空きがなければ以下の画像のようなエラー文がVeeamのコンソール上で表示され、バックアップが実行できないのでご注意ください！
workerがデプロイされる流れは？
次にworkerがデプロイされる流れをコンソールの画像を見ながら確認していきましょう！
①手動でバックアップを実行してみましょう！ バックアップを実行したいポリシーにチェックをいれ、「開始」ボタンをクリックします。
②GCPのコンソール上でworkerが起動しているか確認してみましょう！
ちゃんとworkerがデプロイされていることが確認できますね！
③veeamのコンソール上でバックアップの経過を確認してみましょう！
実行されていることが確認できますね！
④お、完了しました！
GCP上のコンソールでもworkerが削除されていることが確認できますので、確認してみてください！
終わりに
最後まで読んで頂きありがとうございました！
バックアップはどのシステムをつくる上でも大切なので、ぜひ参考にして頂ければ嬉しいです！
次のブログでは、バックアップ時間測定の検証結果について執筆したいなと考えています！
それでは皆様よいお年を！