Cloud

またしてもBlogが止まっていたのをようやく修復

以前書いたの項目と同じ症状

  • KernekのUpgardeがうまく行かない → カーネルが見つからず(link切れになっている)

この結果再起動した際にカーネルパニックが発生して起動しなくなる。
回復の手段はわかっているのだが面倒すぎる。ということで一旦GCEの自動更新をやめておこうと思う。

復旧手順は変わらないが

  1. 以前のGCEのストレージを「複製」
  2. 新しいGCEサーバ作る、複製したディスクをセカンダリにつける。Versionは合わせておく(今回あであれば 22.04 )
  3. 起動したら以下のコマンドを実行
mkdir /data_disk
mount /dev/sdb1 /data_disk
for m in dev proc run sys; do mount -o bind {,/data_disk}/$m; done
chroot /data_disk
apt update
apt upgrade

実際に手動で upgradeしてもすごい時間がかかるのでこれはうまく言ってないのじゃなくてGCE側のUpdateのTimeoutでも起こっているんじゃないのかとも思われる。

GCEがKernel Panic で起動しないときの対処

症状

  • GCEに対して再起動を実施したら起動してない
  • シリアルポートログを確認すると「Kernel Panic」で停止している
  • Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

環境

  • Ubuntu 22.04 ( upgradeで来ている)
  • e2-micro (一番小さいやつ)
  • ストレージサイズ 10G (一番小さいやつ)

原因

結果的には以下が原因となっていた

  • Kernel Update の際にディスクの容量不足?でUpdate が正常に行えず、かつロールバックも出来ない状態になっていた
  • その際に、ディスク装置に問題が発生しておりSuperBlockか何処かがおかしい状態になっている(通常の mount が出来ない状態)

対処

GCEなので対処の方法は色々取れるのは助かりました。結果として実施した内容を以下に整理しておきます。原因は別でも似たような症状になった場合には対処できることもあるかもしれません。

  1. ストレージのスナップショットから「ディスクを作成」する
    • 今回は日々スナップショットをスケジュールで実行していたので昨日のスナップショットを利用した(大切、1世代でも取得しておくことをおすすめ)
    • 復元するリージョン・ゾーンと同じ場所に作る
    • サイズをこの段階で20Gに変更しておく(サイズはGCEの場合にはオンラインでも変更可能)
    • 名前は適当に
  2. 新規に同じリージョン・ゾーンでインスタンス①を作成する
    • 復旧の一時的なものなのでマシンスペックは大きめにしておくほうが良い(特にメモリは4Gとかはある方が無難、一時的なのでそれほど費用はかからない想定)
      先程作成した「ディスク」をセカンドディスクとして接続しておく
    • ネットワークなどの通信設定は不要(ディフォルトで作成して問題ない)
    • OSは故障したものと同じOSのバージョンのイメージ(今回はUbuntu22.04 min LTS)を利用して作成する
  3. インスタンス①を起動したらディスクを修復
    • fdisk -l でストレージを確認(/dev/sdb)
    • parted -l で GPTエラーが出ていたら修復する
    • ディスクサイズを大きくしているので以下で拡張をする
      • growpart /dev/sdb 1 を実施してパーティションを拡張(※sdb1がデータが入っている本体のパーティションの場合)
      • resize2fs /dev/sdb1 を実施(ファイルシステムを拡張)
    • ディスクを修復 e2fsck -f /dev/sdb1
  4. ディスクをマウントしてChrootを実施
    • mkdir /data_disk
    • mount -o nouuid /dev/sdb1 /data_disk
    • mount –bind /dev /data_disk/dev/
    • mount –bind /dev/pts /data_disk/dev/pts
    • mount –bind /proc /data_disk/proc
    • mount –bind /sys /data_disk/sys
    • chroot /data_disk
    • これでルートが追加したディスクになっていることを確認しておく
    • 何故か初期で mount -o nouuid でマウントできずオプションなしでマウントすることになった(同じマシンで起動する場合には競合する可能性があるので注意)
  5. Kernelの再導入
    • 色々この段階で調査をしているのだが今回はKernelが半端に入っているので再度導入を行う(実際には apt –reinstall install linxu-xxx をしたのだが実行が出来ず結果的には apt autoremmove で修復が実施された
    • Kernelを導入するとその段階でGrub系のコマンドも実行される
    • 今回のケースではない場合には grub install や update-grub などを利用してブート (/boot) を修復する必要があるかもしれない。
    • インスタンス②を停止
    • 編集からディスクを取り外す
  6. 新規にインスタンス②を起動
    • 最終的にはこのインスタンス②を利用するか、壊れたインスタンスのディスクを取り外しても良い(怖いのでここは②を利用して確認をおこなう)
    • 作成時に、先程のディスクを boot diskとして選択する
    • ネットワークの設定などは壊れたインスタンスの内容と同じにしておく
    • 起動を実施してシリアルログから起動メッセージを確認する
    • 起動しない場合にはBoot領域がおかしいなどの場合がある。今回のケースで言えば修復だけして起動したら指定されたKernelがないために起動することが出来なかった。多分 grubで一つ前のものをうまくしてするように修正すれば起動したと思われる

感想

まぁクラウドで良かった。色々試せたので。たまにはスナップショット意外にもマシンイメージとしてバックアップも必要だなと感じた次第。スナップショットの定期実行は便利。Config Managerの自動アップデートの構成(のせい?)は怖い。KernelはUpdateしないほうが無難かもしれない。あとそもそもの原因はストレージ不足とメモリ不足もある気がするのでストレージ拡張した上でZramとかSwapをきちんと定義しておくことで予防にはなる

GCE(VM)のUbuntuサーバのUpgradeの実施とVM Managerの設定

OSのアップグレードを実施するためにSSHで接続をしていると警告を言われるため、シリアルコンソール接続を利用してクラウド側から接続を行います。
Google Cloud Consoleから接続し該当のVMを編集し「シリアルポートへの接続を有効にする」をチェックを入れます。その後「シリアルコンソールに接続」ボタンからブラウザ経由で接続を行います(この機能はホント便利ですね、クラウドでの利用でも不便さを感じないのはすばらしい)

シリアルコンソールを接続しているプロンプトで do-release-upgrade を実行します。(途中かりに接続がきれても再度接続すればつながると思います)

GCEのリソースサイズが小さすぎてものすごい時間(2時間強)を経てやっとUpdate完了、再起動をします。

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic

何故か、自動起動をしてないはずの apache2が自動起動してきたりして焦りましたが disableにしておきます。

VM Managerの設定

https://cloud.google.com/compute/docs/manage-os?hl=ja#ubuntu に記載がありますがUbuntuのバージョンによってもことなりますが今回は18.0以降になるので以下のコマンドで導入をします。

sudo su -c "echo 'deb http://packages.cloud.google.com/apt google-compute-engine-bionic-stable main' > \
/etc/apt/sources.list.d/google-compute-engine.list"
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
vi /etc/apt/sources.list.d/google-compute-engine.list
sudo apt update
sudo apt -y install google-osconfig-agent

これでコンソールからVMの情報が見ることが出来るようになります。

バッチのジョブ作成

GCEでは、apt update を自動的に実施するためのサービスが提供されていますのでこちらを設定してみます。

日々の更新をしたいので apt upgrade を選択します。

作成した後に一度実施するために「今すぐデプロイ」を選択して実行してみます。

上記のように結果が出ています、問題がある場合にはどういう感じで出てくるのかはまだ見れてないのでしばらく利用してから考えていきたいと思います。今回は除外パッケージ等を入れてないのですが実際に本番で使う場合などはコアのパッケージはブロックして手動で確認するなど運用のルールは決めておいたほうがよいでしょう。

(追伸)

  • その後 22.04までアップデートしましたがせっかくのクラウドなのでサーバのリソースを増強してすべき
  • 22.04になった段階でphp-fpmが 7.4系から 8.1系に変わってしまう。通常であれば「保留」になっているのだが無理にdist-upgradeしたために7.4系が消えてしまう問題が起こった(結局リストアして対応)※このサイトのどうしても php8系だとエラーが消えずに対応できず
  • 上記の問題も有り phpが4つバージョンで起動していたので修正
  • 途中で apache2が何故か有効化されてしまったので(このサイトはnginx)で停止
  • 結果としては時間がかかったくらいで大きな問題もなく完了

サポート切れのUbuntu (17.x) のapt updateが失敗する場合の対処

環境
– Google Cloud / Compute Engine / Ubuntu 17.10

サポート切れの古いUbuntuのアップデートをした際に以下のようなエラーで更新ができないことがあります

Ign:1 http://us-east1.gce.archive.ubuntu.com/ubuntu artful InRelease
Ign:2 http://us-east1.gce.archive.ubuntu.com/ubuntu artful-updates InRelease
Ign:3 http://us-east1.gce.archive.ubuntu.com/ubuntu artful-backports InRelease
Err:4 http://us-east1.gce.archive.ubuntu.com/ubuntu artful Release
404 Not Found [IP: 35.196.128.168 80]
Err:5 http://us-east1.gce.archive.ubuntu.com/ubuntu artful-updates Release
404 Not Found [IP: 35.196.128.168 80]
Err:6 http://us-east1.gce.archive.ubuntu.com/ubuntu artful-backports Release
404 Not Found [IP: 35.196.128.168 80]
Ign:7 http://security.ubuntu.com/ubuntu artful-security InRelease
Err:8 http://security.ubuntu.com/ubuntu artful-security Release
404 Not Found [IP: 91.189.91.39 80]
Get:9 http://packages.cloud.google.com/apt google-cloud-logging-wheezy InRelease [5483 B]
Ign:10 http://packages.cloud.google.com/apt google-cloud-monitoring-artful InRelease
Err:11 http://packages.cloud.google.com/apt google-cloud-monitoring-artful Release
404 Not Found [IP: 142.250.98.113 80]
Hit:12 http://archive.canonical.com/ubuntu artful InRelease
Err:9 http://packages.cloud.google.com/apt google-cloud-logging-wheezy InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05 NO_PUBKEY FEEA9169307EA071
Reading package lists… Done
E: The repository 'http://us-east1.gce.archive.ubuntu.com/ubuntu artful Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://us-east1.gce.archive.ubuntu.com/ubuntu artful-updates Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://us-east1.gce.archive.ubuntu.com/ubuntu artful-backports Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://security.ubuntu.com/ubuntu artful-security Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://packages.cloud.google.com/apt google-cloud-monitoring-artful Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://packages.cloud.google.com/apt google-cloud-logging-wheezy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05 NO_PUBKEY FEEA9169307EA071

1)キーを更新します。
これでKeyのエラーは解消されます

curl -f https://packages.cloud.google.com/apt/doc/apt-key.gpg \
| sudo apt-key add -

2)リポジトリの接続先が古いので修正します

参照先を http://old-releases.ubuntu.com/ に修正します。archiveもsecurityも同様です。Compute EngineのリストはGoogleのミラーを示しているので一旦Ubuntuの方に変更しておくのもよいかと思います。ググるとリストから取り除くみたいな記述もあるのですがそれをするとUpdateできなくなりますので修正しておきます。

deb http://old-releases.ubuntu.com/ubuntu/ artful main restricted
deb http://old-releases.ubuntu.com/ubuntu/ artful-updates main restricted
deb http://old-releases.ubuntu.com/ubuntu/ artful universe
deb http://old-releases.ubuntu.com/ubuntu/ artful-updates universe
deb http://old-releases.ubuntu.com/ubuntu/ artful multiverse
deb http://old-releases.ubuntu.com/ubuntu/ artful-updates multiverse
deb http://old-releases.ubuntu.com/ubuntu/ artful-backports main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ artful-security main restricted
deb http://old-releases.ubuntu.com/ubuntu/ artful-security universe
deb http://old-releases.ubuntu.com/ubuntu/ artful-security multiverse

これで無事に apt upgrade 出来るようになったかと思います。

Azureのプランを無料期間からアップグレードする

マイクロソフトの提供するクラウドサービスであるAzureを最近利用させていただいていました。 1ヶ月間様々なサービスが利用でき、その後もクレジットカードを登録することで無料枠を利用することが出来ます。(このあたりは、AWSやGCPなどと同様ですね)。

無料期間中の実績

費用のプランニングをする画面があります。今回はVMを利用して、Diabloのゲームサーバとして利用をさせていもらいました。 サービス自体のON/OFFは結構時間がかかる印象ですがそういった構成が終わったあとは特に問題なく安定して利用することが出来た印象です。そして日々のバックアップは良いですね。 何度かバックアップから新規のイメージを復元しそこでソフトウェアの設定を試したりしてました。

12ヶ月無料のサービスの範囲でとして適応されるのか評価をしている項目がありました。データのダウンストリーム(AzureからClientに送信されるデータ)がかなり超過しています。果たしてこれは、Remote Desktopの画面のためなのか本当にゲームサーバから送信されたデータであるのか

リソースグループをサーバもクライアントも同じにしてしまったのでこれ以上はわからないですが日々の差がだいぶあることからRemoteDesktopなんじゃないかなと思います。

プランのアップグレード

左上に、 アップグレード のボタンが出ていますのでクリックをします。

プランを テクニカルサポートなし を選択してアップグレードを実施します。

通信料金を、計算ツールで調べてみます。

https://azure.microsoft.com/ja-jp/pricing/calculator/?service=bandwidth を調べてみるとなかなかの費用になりそうです。 利用の超過を見逃さないように予算アラートを設定しておきました。 利用状況についてはまた来月見ていきたいと思います。

上部へスクロール