Veeam Backupで取得するVMware vSphere環境の変更を行った。新しい環境のバックアップを行ったところ、別の仮想サーバとして認識され、使用されるライセンス数が2倍になった。
Inventoryで不要なサーバを削除しても使用されるライセンスは減らない。（Inventoryで不要なサーバを削除するためには、利用されているバックアップタスクの削除も必要）
不要なサーバで、使用されているライセンスを減らすには、以下の作業でライセンス割り当てを解除する。
1. Veeam Backup の管理コンソールを開く
2. メニューからライセンス（License）を開く
3. 「Instances」のタブを開く
4. 「Manage…」をクリックする
5. ライセンスを使用しているサーバの一覧が表示されるので、NameとHostをみて、不要になったサーバを選択して、「 Revoke」をクリックする
6. 「Revoke」のところ、不要な台数だけ繰り返す。
7. 終わったら、OKで閉じていく。
Veeam Backupで仮想基盤のバックアップを取得している場合、vCenter Server や、ダイレクト登録しているESXiを入れ替えて、仮想マシンを移行すると、同じ仮想マシン名でもVeeam Backup上は別のVMとして認識される。そのため、既存のバックアップタスクでは、移行先のホストをVeeam Backupに登録しても、バックアップ対象の仮想マシンは切り替わらない。
新しい仮想基盤にVMを移行させた場合は、Veeam Backupのバックアップタスクで、バックアップ対象となるVMを、指定しなおす必要がある。具体的には、個別のタスクで旧ホスト側のVMを削除して、新しいホストのVMを指定しなおす。このとき、別VM扱いになるので、バックアップ容量は気を付ける必要がある。
現在、稼働している.NETのアプリが、どのバージョンのライタイムで、アプリケーションが動作するようになっているのかを調べてみる。この方法は、.NET5よりも後の.NETアプリについて、調べることができる。
アプリのフォルダで、下記の名前のファイルがあるかを調べる。[appname]の部分には、そのアプリの名前がついている。
[appname].runtimeconfig.json次のそのJSONファイルを開く。メモ帳などのテキストエディタで開けばよい。
下のような中身になっているので、「tfm」や「version」の部分を確認し、どの.NETバージョンを利用するようになっているのかを確認する。
{
"runtimeOptions": {
"tfm": "net8.0",
"includedFrameworks": [
{
"name": "Microsoft.NETCore.App",
"version": "8.0.5"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "8.0.5"
}
],
"configProperties": {
"System.GC.Server": true,
"System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
"System.Reflection.NullabilityInfoContext.IsSupported": true,
"System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
}
}
}参考： https://learn.microsoft.com/en-us/dotnet/core/runtime-config/
Veeam Agent for Microsoft Windows 6では、64TBをこえるボリュームのバックアップを取得できない。バックアップタスクは作成できるが、バックアップの取得時にエラーになる。ボリューム全体ではなくて、フォルダ指定でもエラーになる。
これは、Veeam AgentがVSS（Volume Shadow Copy Service ）を利用してバックアップを行っているためである。VSSは、64TBをこえるとスナップショットの作成時にエラーが発生する。そのため、Veeam Agentでのバックアップもエラーになる。
WindowsのOS側の制約なので、１つのボリュームで64TBにならないようにパーティションをわけて、そのボリュームのバックアップをVeeam Agentでとることになる。
参考：
https://helpcenter.veeam.com/docs/agentforwindows/userguide/system_requirements.html?ver=60
.NET6のサポート終了が近づいているので、.NET8に変更して実行したところ、SQL Serverとの接続でエラーが発生した。
An unhandled exception occurred while processing the request.
Win32Exception: 信頼されていない機関によって証明書チェーンが発行されました。
Unknown location
SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - 信頼されていない機関によって証明書チェーンが発行されました。)
Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, bool breakConnection, Action<Action> wrapCloseInAction)「Microsoft.Data.SqlClient パッケージ」の破壊的変更の影響だった。対処としては、ConnectionStringsの接続文字列の最後に、「TrustServerCertificate=True;」を追加した。下記みたいな感じ。
"ConnectionStrings": {
～～～略～～～;Database=DBname;TrustServerCertificate=True
},これでもう一度実行して、実行できることを確認した。
参考： https://learn.microsoft.com/ja-jp/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7
インテルの13世代のCore i7（Core i7-1360P）のノートPCが安定しない。BSODになったり、動作が重かったり、グラフィック部分で暗転するときがあったり、などなど、13世代Core i7のノートPCの不具合が多い。安定して動いているノートPCもあるので、個体差がある。
BSODの原因ばかりを探っていたが、PCとしてのパフォーマンスが悪いのでパフォーマンスを強化する方向で調べ方を変えたところ、以下の記事を見つけた。
Intel issues statement about CPU crashes, blames motherboard makers — BIOSes disable thermal and power protection, causing issues
https://www.tomshardware.com/pc-components/cpus/intel-issues-statement-about-cpu-crashes-blames-motherboard-makers
PC側の動作が遅いので、高パフォーマンスで使うようにしてもらっていたが、逆効果になっている可能性がある。BIOSの問題かどうかわからないが、電力消費が増えることによる劣化か安定しないか、その可能性が出てきた。パフォーマンスコアをうまく使えていないのかと思っていたけれど、そもそもCPUが外れか、制御が甘々でパフォーマンスが出ないのかも。14世代のCPUも似たような問題を抱えていそうなので、新モデルが出て、乗り換えるのも得策ではなさそうだ。
とりあえず、ソフトウェア制御というかアップデートなどで安定してくれるといいのだけど。打つ手がないPCトラブルは大変なので。
BitLockerを悪用してPCを暗号化するランサムウェア。Kasperskyが注意喚起
https://pc.watch.impress.co.jp/docs/news/1594922.html
VBScriptとPowershellの実行に気をつけろ、というが・・・サーバだったらPowershellは多用しているので、難しいかも。
侵入されないようにするしかない気がする。
最近、営業系の迷惑メールで件名が「RE: 日程調整の件」とか「RE: XXXXの件」のものが多く来るようになった。
今までやり取りをしたこともなく、返信のREの前のメールもない。それなのに、いままでやり取りをしている感を出して、返信のような感じで営業メールを送ってくるところが増えた。そういうメールは、だいたいフレンドリーだったり、失礼な感じのメールが多い。
これ、どこかの営業セミナーか何かで紹介されているのだろう。開封率が高いとか、ぼけて返信があるとか、そういうものを誘発しているのだろう。もう、分類的にはフィッシングメールに近いような感じだ。フィルタしにくいし、これを開いて消す手間もあるので、本当に迷惑。
内容勝負ではなく、見た目のひっかけやすさだけを目的にした営業メールは、DMとしてのインフラを崩壊させるわけで、だれも得をしないはずだ。大量のメールをGoogle（Gmail）やMicrosoftが規制するようになっているので、プラットフォームとしてかなりきつい。そうなると、ウェブでのマーケティングになるのだろうけれど、こっちも悪質なものが増えて、ブロックされるケースが増えている。そうなると初心に戻って、検索エンジンから流入になるわけだが、こっちも怪しい。そうなると最後は、なんだろうか。展示会とかオフライン活動になってしまうのだろうか。いろいろと考えさせられる。
Google Cloudが起こしたミスで、クラウド環境がふっとんだ、というニュースがあった。本来消すはずのない企業アカウントを消してしまい、Google Cloudの構成が吹っ飛び、冗長化されていた設定も吹っ飛んだ、という。アカウントを消されたら、何もできない、復旧もできない、というわけだ。
Google Cloud、豪年金基金のアカウントを誤削除 予備も誤削除 他社でのバックアップでなんとか復旧 – ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2405/13/news090.html
（復旧できたようなのでよかった、と思う。教訓にもしやすい。）
クラウド環境のハードウェア的な問題であれば、冗長構成は役に立つし、バックアップも機能する。でも、メインのアカウントが、なんらかの理由で消えたり、垢バンされたりすると、それらは使えない、という事例ができた。これに対応しようとすると、まったく別のクラウド環境にバックアップを持つ、構成が消されたりクラッシュしてもいいように再構築できる資料を用意するしかない。アナログだけれど、それが一番確実かもしれない。構築が自動化されているのであれば、構成レシピは別のところに保存しておく、というのも有効だろう。
いい教訓がうまれた、と思う。
VMwareアカウントが、Broadcomアカウントに移行されるという通知が来たのが4月末ごろ。日本のゴールデンウィーク期間にBroadcomアカウント側にライセンスなどが移行されるとされていたのだが、まだ終わっていないようだ。Broadcomのアカウントでログインすると、まだ移行中であることが表示されている。メンテナンスの期間は終わっているはずなんだが。保有ライセンスも、ライセンスキーも、アップグレードもできないので、早く移行が終わってほしい。
Xの投稿をみていると、ユーザによっては、GWの期間に通知されたようで。休みの間にVMware側のアカウントが使えなくなっているとか。いまに始まったことではないが、Broadcomの対応は急というか雑というか、ひどいものだ。