SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

VM Role のパッチマネジメントを考える

leave a comment

Windows Server 2008 R2 SP1 の提供も開始されましたので、VM Role のパッチマネジメントについて自分なりに考えていきたいと思います。
今回のパッチマネジメントは修正プログラム (OS / アプリケーション) を範囲としています。
# アプリケーションの更新をパッチマネジメントというかは微妙な気がするのですが…。

軽く試したところ、VM Role で Windows Server 2008 R2 SP1 を動かすことはできました。image

■Web / Worker Role のパッチマネジメントについて

まずは、Web / Worker Role のパッチマネジメントについてみていきたいと思います。

Web / Worker Role のサービス構成ファイル (.csfg) では、[osFamily] [osVersion] の属性を指定することができます。
Service Configuration Schema

この属性を使用することで、Windows Azure Guest OS を指定することができます。
Windows Azure Guest OS Releases and SDK Compatibility Matrix

VWD 2010 + Windows Azure Tools v1.3.31122.1601 を使用している場合は、[osFamily=”1” osVersion=”*”] として設定がされていますので、Azure Guest OS は OS Family として Windows Server 2008 SP2 が使用され、OS Version としては自動アップグレードで最新のパッチレベル (osVersion) の OS が使用される設定となっています。
# 現状は、osFamily / osVersion 属性を指定しない場合も Windows Server 2008 SP2 + 最新の osVersion (*) になるみたいですね。

同一の OS Family 内で 最新の OS Version が自動アップグレードされるため、自動アップグレードにより OS Family が変わるということは現状は無いようです。
# OS のライフサイクルサポートが終了するとどうなるかは分かりませんが…。

サービス構成ファイルだけではなく、Management Portal からも [Configure OS] から OS Family / OS Version を設定することができます。
image

[Configure OS] をクリックすることで、OS Family / OS Version を変更することができます。
Management Portal から変更ができますので、最新の OS はパッケージを再作成 / 再展開しなくて利用することが可能です。
image

OS Family と OS Version は任意の組み合わせを設定することが可能です。
image
image

PasS 型のクラウドサービスのメリットとして、OS の準備 / セキュリティパッチの管理を [サービス提供者主体] にできるというところがあると思います。 
逆にサービス提供側が OS のアップグレードを強制するということができるという側面もありますが。
# 現時点では実施されたという事例は無いようですが、致命的な脆弱性があった場合には、通知 / 一定の猶予期間を置いた後に強制的なアップグレードを行うという考えはあるそうです。

Web / Worker Role を使用している場合は、サービス提供側が状況に応じて適切なパッチが適用されている OS を準備してくれるため、利用者は自身でプラットフォーム側にパッチを適用した環境を準備する必要はなく 状況に応じてサービス提供者が用意しているパッチ適用済みの OS を適宜使用することができます。

アプリケーションの更新に関してですが、Web / Worker Role のパッケージにはアプリケーションが含まれていますので、最新のアプリケーションを含むパッケージをアップロードすることでアプリケーションの更新を実施することができます。

簡単ではありますが図示するとこのような形になりますでしょうか。

image

サービス提供者

  • パッチ適用済みのベース OS の提供
  • インスタンスが実行される物理環境の維持 / 管理

サービス利用者

  • 使用するベース OS の選択 (OS Version を Automatic にすることで自動化可能)
    • 同一 OS 内でのパッチレベルの変更のため、Windows Server 2008 → Windows Server 2008 R2 というような OS のバージョンが変更されるようなことはない
      # 2008 R2 SP1 が Azure のリリース以降の最初の SP になりますので、これがどのような扱い (2.x 系なのかそれとも違うバージョンか) になるかはまだ情報が集められていません。
  • アプリケーションのパッチメンテナンス

という形でパッチマネジメントをしていく形になるかと思います。

Web / Worker Role のパッチマネジメントに関しては、以下の技術資料がとても分かりやすいです。
Windows Azure 上での Web アプリケーション開発基礎

 

■VM Role の Configure OS について

本題の VM Role のパッチマネジメントを考えていきたいと思います。
まずは、VM Role の Configure OS について。

VM Role では、[Configure OS] をクリックすることができません。
# Configure OS は常にグレーアウトした状態になります。
image

パッチマネジメントに関してはサービス提供側ではなく、[利用者主体] で実施する必要があります。

VM Role の場合、サービスを提供するために必要となるミドルウェアも含めて利用者側が用意する必要があります。

そのため、利用者が

  • OS (Windows のセキュリティパッチ / サービスパック)
  • ミドルウェア (任意でインストールしたミドルウェアの修正プログラム)
  • アプリケーション (作成したアプリケーションの不具合対応をしたモジュール等)

等を必要に応じて判断をして自身で適用 (環境の管理) する必要があります。

また、現状の VM Role では OS のバージョンアップをしたいといった時も、利用者が OS のイメージを準備する必要があります。

VM Role は自分で準備した環境を Windows Azure 上にアップロードができる [自由度の高い (カスタマイズの幅が広い) 環境] となっています。
その自由度の高さのトレードオフとして Web / Worker Role と比較し、運用コストが大きくなる (利用者が独自に運用方法を考慮する必要がある) 環境 ということを意識して使用する必要があると思います。

こちらも図示をするとこのような形になるかと。

image

サービス提供者

  • インスタンスが実行される物理環境の維持 / 管理

サービス利用者

  • 使用する OS の準備
  • OS のパッチメンテナンス
  • 導入しているミドルウェアのパッチメンテナンス
  • アプリケーションのパッチメンテナンス

インスタンスを実行するための環境の提供以外はサービス利用者が運用を考慮する必要が出てきます。

 

■VM Role の基本構成

それではパッチを適用するときにはどうすればよいでしょうか?
まずは、VM Role の基本構成を振り返ってみたいと思います。

VM Role デプロイの基本は下図のようになります。
image

VM Role でインスタンスが作成される際には、csupload を使って [アップロードした VHD が起点] となります。
インスタンスのリイメージや、インスタンスが実行されている H/W に障害が発生した際などには、[アップロードした VHD の内容でインスタンスが再作成] されることになります。

 

また、VM Role のインスタンスの基本構成はこのような形になります。
# 必要に応じて Azure Drive / Azure Storage を使うことになるかと。
image

アップロードした VHD は原則 [非永続領域] として考える必要があります。
データを永続化したい場合には、Azure Storage や SQL Azure、Azure Connect を使用してオンプレミスの環境にデータを保存する等の対応を考量する必要があります。

VM Role は [csupload でアップロードした VHD が起点] となりますので、パッチマネジメントはアップロードする VHD に対して実施する必要があります。

 

■VM Role のパッケージについて

Web / Worker Role では、パッケージ (.cspkg) / 構成ファイル (.cscfg) をアップロードすることでインスタンスを使用できるようになります。
VM Role では VHD (.vhd) / パッケージ (.cspkg) / 構成ファイル (.cscfg) をアップロードすることでインスタンスを使用できるようになります。
VM Role を使用する場合は、OS のイメージは利用者が用意する必要がありますので VHD をアップロードするという作業が追加で必要となります。

 

このパッケージの内容ですが、Web / Worker Role と VM Role では内容に大きな違いがあります。

  • Web / Worker Role
    • アプリケーションと配置に必要な情報 (定義ファイルの内容を含む) を含んだパッケージ
  • VM Role
    • 配置に必要な情報 (定義ファイルの内容を含む) を含んだパッケージ

VM Role のパッケージ (.cspkg) は サービス定義ファイル (.csdef) の XML を作成して、SDK に含まれている [cspack.exe] を実行することでパッケージを手動で作成することも可能となっています。

VM Role のパッケージにはアプリケーションは含まれていません。パッケージは [サービスモデル (インスタンスの基本構成) を定義したもの] になります。

パッケージの [.cspkg] ファイルは ZIP 圧縮のファイルですので拡張子を [.zip] にすることで展開することが可能です。
実際にパッケージを展開するとこのようなファイル構成になっています。
image

こちらが Web Role 用のアプリケーションのパッケージになります。
image

ファイルの構成としては同じなのですが、[.cssx] ファイルのサイズが異なっています。
VM Role のパッケージは定義ファイルがメインになりますので、ファイルサイズはかなり小さくなっています。

 

■VM Role のアプリケーションの変更

それでは、アプリケーションの変更 (アプリケーションに対してのパッチ適用) を考えてみたいと思います。

そのため、VM Role の場合、アプリケーションは VHD 側に含まれることになります。 
# アプリケーションの構成方法によっては、Azure Storage 側に寄せることもできるのかな??
image

パッケージにはアプリケーションが含まれていませんので、パッケージの入れ替えを行ってもインスタンスが新しい定義情報を元に再作成されるだけでアプリケーションの更新は行うことができません。

アプリケーションの更新を行うためには VHD の入れ替えを行う必要があります。
image

VM Role の VHD は OS を含んだ形になりますので、アップロード時に圧縮された形式になっても 6GB 以上のサイズになるかと思います。
そのため、アプリケーションを更新するたびに毎回 VHD をアップロードするのは少し厳しいですよね…。

そこで、アプリケーションの更新をする際には [差分 VHD] を使うのが効率が良いかと思います。

VM Role では一段階であれば差分 VHD を使用してインスタンスを作成することができます。
# 余談ですが、アップロード後の VHD の名称に [_] (アンダースコア) を使うと [A parameter was incorrect. Details: The image name is invalid.] というメッセージが出てアップロードできなかったりします。
image

VHD を以下のようで管理するとアプリケーションの更新時にアップロードするファイルのサイズを抑えることができると思います。
image

最初の親 VHD には初期リリースのアプリケーションも含めてしまったほうが効率が良いかもしれませんね。

多段の差分 VHD はできませんが、
image

一つの親 VHD に複数の差分 VHD を関連付けることは可能ですので、差分 VHD を使用してアプリケーションの世代管理を実施することはできます。
image 
image

ファイルのアップロードの時間を短くし、アプリケーションの更新をする場合は、

  1. 最新のアプリケーションを含んだ差分 VHD をアップロード
  2. アップロードした差分 VHD を親 VHD と関連付け
  3. アップロードした差分 VHD を使用するようにインスタンスの構成を変更

という流れがよいかと思います。

アップロードするサイズや時間を気にしないのであれば、
image
というような、アプリケーションの世代ごとに一つの VHD で管理するのが一番楽だと思います。
# この後の OS / ミドルウェアのパッチ適用を考慮するとこの形が一番いいのですけどね…。

 

■OS / ミドルウェア のパッチ適用

それでは、OS / ミドルウェアのパッチ適用を考えてみたいと思います。
# この 2 種類に関しては似たような適用になるかと思い同一のカテゴリとしています。

ここでも差分 VHD が使用できればよいのですが、差分 VHD には以下のような制限があります。
仮想ハード ディスクについて

差分ディスクを使用する前に、親ディスクを書き込み禁止にするかロックすることをお勧めします。そのようにしないと、他のプロセスによって親ディスクが変更された場合、その親ディスクに関連するすべての差分ディスクが無効になり、その差分ディスクに書き込まれたデータがすべて失われます。

そのため、差分 VHD を利用し手いる場合、親 VHD に以下のようなパッチ適用はできないという事になります。
そのため、読み取り専用として書き込みをロックするのが推奨されています。
image

 

差分 VHD を使用している環境にパッチを適用する際には、以下のように適用をする必要があります。
image

親 VHD ではなく差分 VHD に対してパッチを適用しています。
少量のパッチや設定変更であれば、差分 VHD に適用をしてもファイルのサイズが大きく増えるということはないかと思います。
ただし、OS のサービスパックやミドルウエアのフィックスパックに関しては変更が多いため、適用をすると差分 VHD のサイズがかなり大きくなります。

ある程度サイズが大きくなった場合、一度差分 VHD を結合して親 VHD に変更を反映したほうが良いかと。
image

 

■Sysprep の注意点

VM Role のパッチマネージメントを行うにあたって一つ注意しなければいけないのが [Sysprep] になります。
Introduction to the VM Role Development Process に VM Role の Sysprep 実行についての記述があります。

現状の手順では VM Role のイメージは [一般化 (Generalize) した Sysprep] を実行する手順となっています。
image

一般化した Sysprep で注意をしなければいけないのが、[ライセンス認証クロックのリセット] になります。
インストール後の初期状態では、[slmgr –dlv] の実行結果は以下のようになっています。
image

以前、Windows 7 の再初期化数について という投稿で記載をしたのですが、上の画像の赤枠で囲んでいるカウントは一般化した Sysprep を実行するごとに数値が減っていき、0 になると Sysprep でエラーとなります。

そのため、一般化した Sysprep は通常 3 回までしか実行することができません。
# KMS で認証させれば 3 回以上実行することができるはずですが。
image

以下のパターンでの Sysprep を考えてみます。
image

image

初回の展開時には上記 VHD で問題はないのですが、内容の変更が必要になった場合は、Sysprep した状態が起点となるため、必ずライセンス認証クロックがリセットされ Rearm Count が減少していきます。

ライセンス認証クロックのリセットをスキップするためには SkipRearm を有効にした応答ファイルを作成する必要があります。

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="generalize">
    <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <DoNotCleanUpNonPresentDevices>true</DoNotCleanUpNonPresentDevices>
      <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
    </component>
    <component name="Microsoft-Windows-Security-Licensing-SLC" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <SkipRearm>1</SkipRearm>
    </component>
  </settings>
  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <InputLocale>en-us</InputLocale>
      <SystemLocale>en-us</SystemLocale>
      <UILanguage>en-us</UILanguage>
      <UserLocale>en-us</UserLocale>
    </component>
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <TimeZone>UTC</TimeZone>
      <DisableAutoDaylightTimeSet>true</DisableAutoDaylightTimeSet>
      <OOBE>
        <ProtectYourPC>3</ProtectYourPC>
        <SkipMachineOOBE>true</SkipMachineOOBE>
        <SkipUserOOBE>true</SkipUserOOBE>
      </OOBE>
      <UserAccounts>
        <AdministratorPassword>
          <Value>[暗号化されたパスワード]</Value>
          <PlainText>false</PlainText>
        </AdministratorPassword>
      </UserAccounts>
    </component>
  </settings>
</unattend>

黒太字になっている箇所がライセンス認証クロックのスキップをするための設定になります。
# 途中で改行されている箇所は 1 行で入力します。

SkipRearm を設定することで、ライセンス認証クロックのリセットをスキップすることが可能となります。
image

[cscript.exe "c:WindowsSystem32slmgr.vbs" –ato] を明示的に実行 (または同期コマンドとして設定）しなくても放っておくと認証はいけそうですね。
# 認証モードは [KMSCLINET channel] にしておく必要がありますが。(MAK で認証してしまっていると状況が変わると思います。)
image

本番運用する前に、どのように環境の維持をするためのメンテナンスをするかを考えていかないといけないですね。

この辺を考えないで VM Role を使用すると、

  • 毎回完全な VHD をアップロードする必要があるために更新に時間がかかる。
  • 3 回 Sysprep してそれ以降変更できない。

といった状況に陥ってしまうかもしれないですね。

Written by masayuki.ozawa

2月 21st, 2011 at 12:27 am

Posted in Windows Azure

Tagged with ,

«
»

Leave a Reply

CAPTCHA

*