2023年01月
2023年01月27日
DELL のサーバーを購入しました｡
初期設定をするためにOSのインストールから作業をしていました｡
するとすでにパーティションが切られていました｡
ESP という領域と OS と名前がついている2Gぐらいのパーティションの2つがありました｡
正直なところどのような用途なのか､またDELLサーバーには必要なのか･･･｡
気持ち悪いので削除してしまいました｡
結局これらの初期に用意されていたパーティションは削除しても問題ありませんでした｡
ちなみに ESP(EFI System Partition)ということのようです｡
検証していませんが､DELL の Lifecycle Controller を利用するとOSの導入が簡単にできるのですが､これを利用すると作成されるようです｡(詳細は不明)
初期設定をするためにOSのインストールから作業をしていました｡
するとすでにパーティションが切られていました｡
ESP という領域と OS と名前がついている2Gぐらいのパーティションの2つがありました｡
正直なところどのような用途なのか､またDELLサーバーには必要なのか･･･｡
気持ち悪いので削除してしまいました｡
結局これらの初期に用意されていたパーティションは削除しても問題ありませんでした｡
ちなみに ESP(EFI System Partition)ということのようです｡
検証していませんが､DELL の Lifecycle Controller を利用するとOSの導入が簡単にできるのですが､これを利用すると作成されるようです｡(詳細は不明)
2023年01月26日
DELL PowerEdgeサーバーに OS をインストールしていました｡
あまりツールは利用せずに素の状態でOSをインストールしました｡
いくつかのドライバーは無難に当てることができましたが､一つ不明なまま残ってしまいました｡
デバイスマネージャーを確認すると以下の情報が出ていました｡
ACPI\INT34C6\2&DABA3FF&0
場所については､ Microsoft ACPI-Compliant System という記載も｡
結論からいうと､DELLのホームページから､以下のドライバーをインストールすると解決しました｡
インテルTatlowプラットフォームLPSS用ドライバー
チップセットのドライバーのようです｡
インストール後は以下の記載に変更されました｡
Intel(R) Serial IO GPIO Host Controller - INT34C6
あまりツールは利用せずに素の状態でOSをインストールしました｡
いくつかのドライバーは無難に当てることができましたが､一つ不明なまま残ってしまいました｡
デバイスマネージャーを確認すると以下の情報が出ていました｡
ACPI\INT34C6\2&DABA3FF&0
場所については､ Microsoft ACPI-Compliant System という記載も｡
結論からいうと､DELLのホームページから､以下のドライバーをインストールすると解決しました｡
インテルTatlowプラットフォームLPSS用ドライバー
チップセットのドライバーのようです｡
インストール後は以下の記載に変更されました｡
Intel(R) Serial IO GPIO Host Controller - INT34C6
2023年01月24日
サーバーの入替作業を行っていました｡
そのとき ActiveDirectory のサーバーを交換するためにまず降格作業を行おうとしました｡
作業中､､､といってもかなり初期段階に以下のエラーが出て止まってしまいました｡
----
ディレクトリ サービスで必須の構成情報が不足しているため、浮動単一マスター操作の役割に対する所有権を判断できません。
----
過去にADが壊れてしまい､いくつもの修復作業を行ったことはありました｡
しかしながら､その後はイベントログなども問題ありませんでした｡
今回の入替作業のときに､バックアップ用のADなどはすでに交換しており､それらとの連携もとりあえずは問題無さそうに見えました｡
直前での作業はIPアドレスを変更していました｡
結局のところこのIPアドレスの変更から､DNSサーバーのエントリーが変更になりこれがまだ反映していない｡そのようなことがなんとなく想像できました｡
エントリーを確認し､nslookup などでも問題ない事を確認し､時間が10分ぐらい経過してから再度作業したところ問題無く進めることができました｡
入替作業の時には､様々な作業が連続して行われるため注意が必要だと思いました｡
そのとき ActiveDirectory のサーバーを交換するためにまず降格作業を行おうとしました｡
作業中､､､といってもかなり初期段階に以下のエラーが出て止まってしまいました｡
----
ディレクトリ サービスで必須の構成情報が不足しているため、浮動単一マスター操作の役割に対する所有権を判断できません。
----
過去にADが壊れてしまい､いくつもの修復作業を行ったことはありました｡
しかしながら､その後はイベントログなども問題ありませんでした｡
今回の入替作業のときに､バックアップ用のADなどはすでに交換しており､それらとの連携もとりあえずは問題無さそうに見えました｡
直前での作業はIPアドレスを変更していました｡
結局のところこのIPアドレスの変更から､DNSサーバーのエントリーが変更になりこれがまだ反映していない｡そのようなことがなんとなく想像できました｡
エントリーを確認し､nslookup などでも問題ない事を確認し､時間が10分ぐらい経過してから再度作業したところ問題無く進めることができました｡
入替作業の時には､様々な作業が連続して行われるため注意が必要だと思いました｡
2023年01月18日
AzureBackup を利用しました｡
要件としては､ファイル毎のバックアップで個別に復元ができることです｡
VMまるっとではありません｡
利用しているディスクは約2Tです｡
仮想マシンには､ Microsoft Azure Recovery Service Agent をインストールしました｡
バックアップのスケジュールを設定するときに､作成したバックアップの保持ポリシーがとても重要でした｡
週ごとのバックアップ(月-金で取得)で設定していたところ､週単位の保持ポリシーというのがデフォルトで有効になっており､これが105週間の保持というとんでもない期間になっていました｡
実際には15日分ぐらいが保持されていたので気づきました｡
････ってことは2T×15日=30Tが消費???
ここまではとてもではないけど不要だったので､バックアップの設定を日単位･･･土日も含めて毎日バックアップの設定にしました｡
上記の懸念であったすでに保持されている15日分のバックアップデータですが､スケジュール設定を変更して､日々の保持を最低の7日にしました｡
その状態で翌日に確認したところ､6日分に減っていました｡よかった｡
ただ料金はいまいちよくわかりません｡
おそらくですが､今回私の設定したディスクはLRSで､2Tがどうも確保されているようです｡
その場合､Standard レベル･LRS では 約3.0067/GB ×2000GB=6013円/月は最低限かかるようです｡
そして実際には7日分バックアップデータが保持されているため､上記金額よりも少し多めにかかるようです｡(おそらく増分や差分などですべてを取得しているわけではないのでしょう)
Azureのコスト分析を確認したところ､毎日230円ぐらい課金されているので､×30で､約7,000円ぐらいが想定されるようでした｡
要件としては､ファイル毎のバックアップで個別に復元ができることです｡
VMまるっとではありません｡
利用しているディスクは約2Tです｡
仮想マシンには､ Microsoft Azure Recovery Service Agent をインストールしました｡
バックアップのスケジュールを設定するときに､作成したバックアップの保持ポリシーがとても重要でした｡
週ごとのバックアップ(月-金で取得)で設定していたところ､週単位の保持ポリシーというのがデフォルトで有効になっており､これが105週間の保持というとんでもない期間になっていました｡
実際には15日分ぐらいが保持されていたので気づきました｡
････ってことは2T×15日=30Tが消費???
ここまではとてもではないけど不要だったので､バックアップの設定を日単位･･･土日も含めて毎日バックアップの設定にしました｡
上記の懸念であったすでに保持されている15日分のバックアップデータですが､スケジュール設定を変更して､日々の保持を最低の7日にしました｡
その状態で翌日に確認したところ､6日分に減っていました｡よかった｡
ただ料金はいまいちよくわかりません｡
おそらくですが､今回私の設定したディスクはLRSで､2Tがどうも確保されているようです｡
その場合､Standard レベル･LRS では 約3.0067/GB ×2000GB=6013円/月は最低限かかるようです｡
そして実際には7日分バックアップデータが保持されているため､上記金額よりも少し多めにかかるようです｡(おそらく増分や差分などですべてを取得しているわけではないのでしょう)
Azureのコスト分析を確認したところ､毎日230円ぐらい課金されているので､×30で､約7,000円ぐらいが想定されるようでした｡
2023年01月17日
ある日､ Postfix SMTP server: errors from XXX というログが大量に出ていることに気づきました｡
XX の作業をした後から･･･というわけでは無さそうなので､完璧な原因については､いまいちよくわかりません｡
ただしきっかけとなるような作業は行っていました｡
あるときメインのサーバーで､ドメインの利用を廃止しました｡
そして過去の経緯から､負荷分散させるための転送サーバーもあり､この設定はそのままになっていました｡
ここからはおそらくですが､この状態で転送サーバーにメールが着信するとメインサーバーに転送します｡
メインサーバーではドメインが削除されているためにこのドメインは受け取り拒否してしまいます｡
普通はこの状態であれば､転送サーバーは､バウンスメールを返すと思うのですが､どうもこのあたりで複数回のエラーになり､ログがたまってしまったようです｡
ログが大量に出てしまい､転送サーバーのディスク40Gがログファイルで埋められてしまいました｡
しかも40Gのログファイルなのでこれを調べることもできずに削除してしまいました｡
途中からのエラー内容は 452 4.3.1 Insufficient system storage となっており､ディスクが枯渇したようでした｡
転送サーバーからも該当のドメインを削除したところ､すぐにエラーが返されるようになって本件は解決しました｡
XX の作業をした後から･･･というわけでは無さそうなので､完璧な原因については､いまいちよくわかりません｡
ただしきっかけとなるような作業は行っていました｡
あるときメインのサーバーで､ドメインの利用を廃止しました｡
そして過去の経緯から､負荷分散させるための転送サーバーもあり､この設定はそのままになっていました｡
ここからはおそらくですが､この状態で転送サーバーにメールが着信するとメインサーバーに転送します｡
メインサーバーではドメインが削除されているためにこのドメインは受け取り拒否してしまいます｡
普通はこの状態であれば､転送サーバーは､バウンスメールを返すと思うのですが､どうもこのあたりで複数回のエラーになり､ログがたまってしまったようです｡
ログが大量に出てしまい､転送サーバーのディスク40Gがログファイルで埋められてしまいました｡
しかも40Gのログファイルなのでこれを調べることもできずに削除してしまいました｡
途中からのエラー内容は 452 4.3.1 Insufficient system storage となっており､ディスクが枯渇したようでした｡
転送サーバーからも該当のドメインを削除したところ､すぐにエラーが返されるようになって本件は解決しました｡
2023年01月16日
