• TOP > 冗長化アーキテクチャ
  • ローリング・アップグレード

冗長化されたシステムであれば、以下のように、
"オン中" であってもローリングしながらシステムを更新できる。

移行メモ（正誤）: 元ページの「"オン中"あってもローリングしながら」は
「"オン中" であっても」の脱字と判断し、補った。

補足（元ページは概要と図のみのため、要点を補う）

ローリング・アップグレードは、冗長化されていれば必ずできるというものではなく、
次の条件が揃って初めて成立する。

• 1 ノードを外しても業務が継続できる（残ノードで負荷を捌ける）
  → N+1 ではなく、更新中も冗長性を保つなら N+2 が要る場合がある。
• 新旧バージョンが同時に稼働してよい（混在期間に互換性がある）
  → ここが最大の制約になる。次節参照。
• ノードを安全に切り離せる（接続の退避、セッションの引き継ぎ）

ローリング・アップグレードの本質的な難しさは、
更新中は新旧のバージョンが同時に動く点にある。したがって、

• データ形式は前方・後方互換であること
  旧ノードが新ノードの書いたデータを読めなければならない。
• 通信プロトコルは相互運用できること
  新旧ノード間、およびクライアントとの間の双方。
• DB スキーマ変更は「加算のみ」で行う
  列の削除や型変更は、旧コードが動いている間はできない。
  「列を追加 → 両方に書く → 移行 → 旧列の参照をやめる → 削除」のように
  複数リリースに分けて段階的に行う（Expand and Contract）。

この制約が満たせない場合は、ローリングではなく
全系停止しての一括切り替えか、
**Blue-Green（新環境を別に構築して切り替える）**を選ぶことになる。

• フェイル・オーバー クラスタリング
  Windows Server 2016 のクラスターの OS ローリング アップグレードにより、
  クラスタを止めずにノードの OS を 2012 R2 → 2016 へ更新できる
  （混在期間は「クラスターの機能レベル」を旧のまま維持し、
  全ノードの更新後に機能レベルを上げる）。
  → サーバ更改（バージョン・アップ移行）

• Hyper-V
  ライブ・マイグレーションで仮想マシンを退避してから
  ホストを更新し、戻す。これがホスト更新時の標準手順になる。
  → Hyper-V 高可用性オプション

• Web / AP サーバ
  ロード バランサから 1 台ずつ切り離して更新し、戻す。
  切り離しの前に**接続の排出（ドレイン）**を待つこと、
  セッションを DB や分散キャッシュに外出ししておくことが前提になる。

• 本 Wiki 内
  • 冗長化アーキテクチャ
  • Hyper-V ライブ・マイグレーション
  • Hyper-V 高可用性オプション
  • サーバ更改（バージョン・アップ移行）

---

Tags: Windows, 仮想化