Windows Server 障害対策
一発目の重要な話
ソフトウェアアシュアランス 付けりゃええやろ理論 が、使えないわけです
後述する 【 90 日ルール 】 を守って再割り当ての権利を行使しながら
ライセンスを ぶん回していく荒業も あるにはありますが
90 日経過していない状態でフリーズしたり、エラー吐いたらどないしますの？
こんな事情から 猛烈に推奨しません
なので、Windows Server で障害対策を行う場合には
移動先にも予備のライセンス準備をする方法が、確実かつ現実的な対策方法
それでは早速、一例を作って御紹介
アクティブ環境 1 台： スタンバイ環境 1 台
シンプル構成のパターンで確認していきましょう
コールドスタンバイやライブマイグレーションなど
障害やメンテナンスの為に、別ホスト環境へ移動させる方式です
全人類が必ずトラップとして引っかかる
【 90 日ルール 】から 紹介しますよ
ホストマシンのスペックは、16 Core CPU が 1 基の筐体として見て下さい
90 日 ルール
⇧
これが 噂の 90 日ルール
アクティブ環境の片側だけにライセンスを用意する場合、
制限が強烈なので現場稼働として現実的ではありませんね
Server 稼働してから 90 日でしょ？ ぐらい、軽く考えられがちですけど
本当の問題はライセンス移動後
スタンバイ Server にライセンスを 移動してから 90 日は戻せません
ここが本当のトラップ部分です。
移動までに 90 日が必要ということは、移動した後から 90 日間も待機期間なのです。
念の為 Microsoft 製品条項の記載もどうぞ
解決サンプル
では、どうしたら違反にならずに移動できるのか。
解決方法を御覧ください。
⇧
どちらのハードウェアに対しても、2 台の仮想マシンを実行できる権利を用意する方法
これでライセンス不足は改善できます
アクティブ Server 上で 2 台の仮想マシンを実行できる権利を持ちながら、
スタンバイ Server 上にも 2 台の仮想マシン実行可能なライセンスを事前に購入しておくわけです。
仮想マシンを主語にすると難しいので、
スタンバイ Server 上の実行仮想マシン数だけで考えると良いでしょう。
スタンバイ Server 上の仮想マシンは、障害が起こっていない状態だと【 ゼロ 】ですね。
障害が起こると【２】になります。
そのために、仮想マシン ２ 台を動かせるだけのライセンスを、
障害が起こる前から用意しちゃいましょうって対応策になってます。
そして面倒な構成が
常時可動しているサーバーが複数台ある場合
VM Were 等では複数ホストが稼働しながら、障害やメンテナンスごとに移動を繰り返す機能がメインです💡
以下に並べた 3 つの画像を 順番に見てもらうと、ライセンスの動きや用意する数が分かりやすいかもしれません
２台構成で両方稼働の場合
両方に 2 台ずつ 仮想マシンを実行できるだけの Windows Server Standard ライセンス、16 Core ずつを用意した前提です。
ここからホスト A が障害でダウンした場合、ホスト B の仮想環境に避難する構成を見てみましょう。
2 枚連続で画像を確認下さい ⇩
⇩
はい！ 御理解いただけましたね！
ホスト B 基板上で 4 つ Windows Server を実行する事になれば、それだけの OS 台数を賄えるライセンスが移動先に無いといけません！
16 コア分 の Windows Server Standard では、2 台同時実行が限度なので
3 台目と 4 台目を実行する権利が不足 します
ライセンス不足が無いように Windows Server Standard ライセンスを
『障害が起こる前に用意してくださらんか？』 理論なのです
つまりは ホスト B に 、仮想マシン 2 台を実行できる権利を上乗せさせる必要があります。
16 Core 分の Windows Server Standard を追加しますから、最初に割り当てていた 16 Core ライセンスと合計で、 32 Core のライセンスをホスト B に用意しておけば違反になりません☺️
サンプル画像は ホスト A から ホスト B に移動しましたけど、逆の動きも想定されますね？
なので、今回の構成でお互いを冗長先として機能させる為には、
Windows Server Standard を 32 コアずつ用意 する事が必要ライセンス条件となってきます
クラスター全部で、仮想マシンを合計どれだけ実行させるかではなく
1 つのハードウェア上に、仮想マシンがどれだけ片寄ってくるか
で、カウントするべし！
物理ホスト 3 台以上でクラスターを組んだ場合も、考え方は同様。
仮にホストが 3 台の場合、 2 台に障害が起こりますと残り 1 台に仮想マシンが片寄りますね。
集まってきた仮想マシンを実行できるだけのライセンスを事前にカウントして準備しておくのが、冗長構成を組む場合の Windows Server ライセンスで重要な部分です
大事な部分なので もう一度
クラスター全体で見るのではなく、物理ハードウェア上にどれだけ実行させる Windows Server OS が集まってくるのかで考えます
これで完璧！
マイクロソフト公式ガイドは、以下サイトからどうぞ
https://www.microsoft.com/ja-jp/licensing/learn-more/volume-licensing-briefs?activetab=volume-licensing-briefs-tab:primaryr5
ソフトウェア アシュアランス 活用
2022/10/01 ついに時は来た。
製品条項に誰にも通知されないまま、いきなり記載された項目。
Windows Server を ソフトウェア アシュアランス 付きで買う場合 ( CAL にも付けないとダメ )
仮想マシンに割り当てる仮想コア数で購入できるオプションがついに解禁。
仮想マシンごとに Windows Server を買う細かいルールは
以前の記事 を参照してもらえると助かります🌝
この ソフトウェア アシュアランス付きで仮想マシンごとに Windows Server を買うケース
最低 8 コアの購入が必須の厳しい購入制限で、メリットを感じませんでしたよね？
ココだけの話
【 90 日ルールに縛られず別ホスト上に移動出来ます 】
こうなりやんした⇓
勘の良い人なら、この疑問が脳裏によぎりませんか？
その権利「ライセンスモビリティ」じゃない？
ええ、ライセンスモビリティだと思います！
それでは確認のために、製品条項の文面で比較してみましょう。
まずはライセンスモビリティ⇓
続きまして
Windows Server 仮想ごとの製品条項⇓
まじ酷似。
何故 Windows Server には、ライセンスモビリティの権利が提供されないのか？
考えられる項目を一つずつ推理考察するでやんす🧐
大きく浮かんだ理由は 2 つ
① ライセンスモビリティと言っても、実は 2 つのモビリティがある
② 物理コア数で買った場合は SA を付けても 90 日ルールに縛られる
① について：SQL Server 等のソフトウェアアシュアランスには、クラウド事業者の共有サーバーを借りて使う場合に BYOL する権利が付いています。これもライセンスモビリティという名称の特典です。
この権利は Windows Server に提供されないので、表記上「ライセンスモビリティ無し」となっている推理
AWS や Google Cloud Platform など大手事業者を含め、レンタルサーバー事業は SPLA というプログラムで Windows Server を事業者サイドでライセンス提供します
顧客は Windows Server ごとレンタル契約しますから、Windows Server ライセンスを持ち込んで利用する概念がそもそも無い製品でもありますね（機械だけを借すハウジング事業者を除く）
② について：物理コア数の購入で ソフトウェア アシュアランス を追加したとしても、90 日以内のライセンス移動を絶対に許さない意志があるから👊
そういった事情で、表記上ライセンスモビリティ権利は提供されてない気がします
しかしながら、仮想マシンの仮想コア数と CAL を ソフトウェア アシュアランス 付きで買えば好きなタイミングで別ホストにマイグレーション出来るのは大きなメリット！
今回の記事冒頭にお伝えした [Windows Server はライセンスモビリティの対象ではない] に関しては、ライセンスモビリティとしての権利はフルサイズで提供されないながらも、90 日ルールを突破できる権利を得られる購入方法が 2022 年にリリースされましたから検討してみて下さい！ となります
物理ホストに VM Were などのサードパーティ製品を使って、8 コア以上の仮想コアを割り振る Windows Server 使う企業はソフトウェア アシュアランス 付きで買ってみても良いんじゃないでしょうか？💸
その場合 CAL の ソフトウェア アシュアランス を忘れてはいけない！
