結局VMを作り直した。なお、1時間ほどでVM削除→ディスクのスナップショット作成→VM再作成→スナップショットから追加ディスクを作成してマウント→etcとhomeの必要な中身を取り出しまで成功した。

Show thread

うーん。

`gcloud compute instances update "${INSTANCE_NAME}" --shielded-learn-integrity-policy`してから`gcloud compute instances stop "${INSTANCE_NAME}"`→`gcloud compute instances start "${INSTANCE_NAME}"`を順にやったら、エラーは出なくなったものの、`Kernel Offset: 0x9e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)`から先に進まなくなってしまった。

正直よく分からないのだけど、インスタンスを作り直した方がよさそうだ。ディスクの中身は拾えたらラッキーか。

Show thread

Shielded VM、めんどくさくなってきた…

ここで止まっている。
```
[ 1.761139] [<ffffffff8b569c10>] ? rest_init+0x80/0x80
[ 1.761883] [<ffffffff8b569c1e>] kernel_init+0xe/0x100
[ 1.762671] [<ffffffff8b58dd37>] ret_from_fork_nospec_begin+0x21/0x21
[ 1.763616] [<ffffffff8b569c10>] ? rest_init+0x80/0x80
[ 1.765624] Kernel Offset: 0x9e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Show thread

なお、シリアルポートの出力は
```
[ 1.756473] [<ffffffff8bb89790>] mount_block_root+0x291/0x2a0
[ 1.757693] [<ffffffff8bb897f2>] mount_root+0x53/0x56
[ 1.758484] [<ffffffff8bb89931>] prepare_namespace+0x13c/0x174
[ 1.759348] [<ffffffff8bb8940e>] kernel_init_freeable+0x222/0x249
[ 1.760232] [<ffffffff8bb88b1f>] ? initcall_blacklist+0xb0/0xb0
```

Show thread

さらに
cloud.google.com/compute/docs/
によると
>>
整合性ポリシー ベースラインを更新するには、setShieldedInstanceIntegrityPolicy 権限が必要です。

整合性ポリシー ベースラインを更新する手順は次のとおりです。
<<

`gcloud compute instances update my-instance --shielded-learn-integrity-policy`
を実行する必要があるとのこと。

Show thread

`json.jsonPayload.lateBootReportEvent.actualMeasurements = [];`

`json.jsonPayload.lateBootReportEvent.policyMeasurements = [];`
を比較すると確かに違っている。

cloud.google.com/compute/docs/
>>
actualMeasurements セクションと policyMeasurements セクションの PCR 値を比較して、前回のブート シーケンスと整合性ポリシー ベースラインとの間の差異がどこにあるのかを判断します。どちらの比較であっても、異なる値を示したものが検証を失敗させた原因です。
<<

Show thread

cloud.google.com/compute/docs/
に沿って
lateBootReportEventで`json.jsonPayload.lateBootReportEvent.policyEvaluationPassed = false;`になっていることを確認。
```js:
json = {};
json.insertId = "2";
json.jsonPayload = {};
json.jsonPayload.bootCounter = "7";
json.jsonPayload.lateBootReportEvent = {};
json.jsonPayload.lateBootReportEvent.policyEvaluationPassed = false;
```

Show thread

CentOS 7 VMのカーネルを更新したらSheilded VMの完全性エラーが出た…

Google Cloud VMのログはJSONなので、gronで解読していく。
```js:
json = [];
json[0] = {};
json[0].jsonPayload = {};
json[0].jsonPayload["@type"] = "type.googleapis.com/cloud_integrity.IntegrityEvent";
json[0].resource = {};
json[0].resource.labels = {};
json[0].resource.type = "gce_instance";
json[0].severity = "ERROR";
```

CentOS 8アップグレード直後にsshが起動しないかもしれないので、
cloud.google.com/compute/docs/
Google Cloud VMのシリアルコンソールを確認しておく。

Show thread

コンソールでみたところ、切り替えた時刻を境目にして、ノコギリのようだったディスクI/Oが平坦になり、ゼロの線を這っているような状態。

明らかにメモリ不足で頻繁にスワップが発生していたせいでパフォーマンスが落ちていたのだとよくわかる。g1-smallで運用できなかったのは残念だけど、仕方ないかな。

Show thread

慢性的パフォーマンス不足に対応するため、BlessedGeeks.Socialのスペックを変更しました。

GCPの無料試用期間が終了したあとの2週間ほど、 をg1-smallで運用してみましたが、CPU使用率を見ていると、少々厳しかったようです。
たびたびレスポンスが悪い状況も見受けられました。
無料期間中に使っていたn1-standard-1(vCPUs x 1、メモリ 3.75GB)に戻すと、過去データから見て5000円/月ほど使う計算になります。
ですのでそこまではせず、Google Cloudが勧めてきたcustom(vCPU x 1、メモリ 2.75 GB)にしています。

g1-smallにした経緯はこちら参照。
blessedgeeks.social/@h12o/1027

GCPの無料試用期限が来たので、BlessedGeeks.Socialのスペックをマシンタイプn1-standard-1(vCPUs x 1、メモリ 3.75GB)から落としてみた。
f1-microとg1-smallのどちらにするかで迷いがある人もいると思うので、私がやった結果を以下の通り共有。

1. マシンタイプf1-micro(vCPU x 1、メモリ 0.6 GB)はさすがに厳しかった。具体的には「We're sorry, but something went wrong on our end.」がずっと出てしまう。
2. マシンタイプg1-small(vCPU x 1、メモリ 1.7 GB)であれば、2〜3分ほどでMastodonの画面にたどり着く。

というわけでマシンタイプg1-small(vCPU x 1、メモリ 1.7 GB)で決まり。

mstdn.jpがずっと不安定で大変そうだなと思ってみていましたが、なかなか安定しそうにありませんね。
皆さまにおかれては、もしよろしければ、この機会にBlessedGeeks.Socialにアカウントを作りませんか?
非力なVMですし特徴もありませんが、最近赤丸急上昇(何が?)のGoogle Cloud上に構築されたサーバです。
登録の際には、アバウトページをよくお読みいただき、BlessedGeeks.Socialの規約や運営方針をご理解の上、@h12o までご連絡ください。
ここまでお読みいただき、誠にありがとうございました。
blessedgeeks.social/
><

のボトルに麦茶、それからはらドーナツで麦麦とした夕方。

ボトルは譲ってもらったもの。耐熱ではなく炭酸飲料にも対応していないので麦茶が最適。そのうち麦コーヒーを入れてみるかもしれない。

Show more