Windows Azure Platform 運用設計 V1.1

Windows AzurePlatform 運用設計
第 1.1 版
2011年6月27日
日本マイクロソフト株式会社
エバンジェリスト
安納順一
http://blogs.technet.com/junichia/
twitter @junichia

本セッションの内容
Windows Azure と Windows Server との違いを理解し、IT インフラの一部として Windows Azure を使用する場合に IT Pro が認識しておかなければならない運用設計の留意点について理解しましょう。
運用設計の留意点
（運用に支障をきたさないための）開発者との連携ポイント

Agenda
はじめに
運用設計の留意点
サービス展開に関する考慮
ローカルストレージに関する考慮
性能に関する考慮
アップデート/アップグレードに関する考慮
ホストOSの障害/メンテナンスに関する考慮
管理/監視の手法に関する考慮
各種ログに関する考慮
コストに関する考慮
開発者との連携ポイント

はじめに

IT Pro にとっての　Windows AzurePlatform とは？
単なるインフラ選択肢の1つ
うまい話なんてあるはずない
使える新機能があれば導入する
お客様への「提案映え」も重要
Windows Server と同様に管理できるのか？
PaaS とか IaaS とかはどうでもよい
新しい管理手法なんて覚えたくない
SE Service で儲けられるか？
SE 作業は無くなる？
作業の質や内容が変わる？

ITPro の責任範囲
アーキテクチャの検討
IT Pro の責任範囲
サービスの展開
管理/監視
Drives
Memory
OS Patches
Networking
Physical Hardware
この部分のコストが意外と高い

作業内容の変化
アーキテクチャの検討
Cloud の責任範囲
IT Pro の責任範囲
サービスの展開
管理/監視
増
Drives
減
Memory
減
OS Patches
Networking
Physical Hardware

IT Pro に求められる作業
運用のベストプラクティス確立
アンチパターンの蓄積
クラウドベンダーごとの性格付け
テクノロジー検証
相互連携（クラウド間、クラウドーオンプレミス間）
他社連携
パフォーマンス予測
どのタイミングでインスタンスを増減するか
コストにも大きく影響
ランニングコスト予測
運用プロセスと密接に関係する
開発者との情報交換

運用時の留意点

Windows AzurePlatform の位置づけ

Windows Server との違い

【大原則】
OS は自分でインストールできない
※VM ロールで回避可能
サービス展開後の環境変更は“消える”可能性がある
環境を作り直して再展開する必要がある
機能の追加/変更はコマンドベース（スタートアップタスク）で実行
作業のやり直しは 15 分以上のロスを発生
開発者との綿密な連携が必須（後述）
OSに対する”管理者”権限は無い
※ADMINモードで回避可能

Windows Server（IaaS）の場合
Application
手動
Windows Server
Windows Server
IIS
IIS
手動
Server（H/W）
Server（H/W）
Server（H/W）
手動
Windows Azure （PaaS）の場合
Application
手動
「サービスのURL」が
DNS に登録される
Windows Server
IIS
自動
PaaSなので、OSをインストールするというプロセスが存在しない
Hyper-V
Server（H/W）
サービスを作成
アプリケーションを展開

FabricController
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
Node
雲の中はこうなってる

Windows AzurePlatform ～ Node の展開
Node 用のOS
PXEBoot用OS
FabricController
ImageStore
Maintenance
OS
Worker
Role
Windows Azure OS
Web
Role
展開・監視
Node
Node
Node
Node
Node
Node

Windows AzurePlatform ～ゲストの展開
ゲストOSに
使用される
テンプレート
ゲストOSに
使用される
FabricController
ImageStore
Maintenance
OS
Worker
Role
Windows Azure OS
Web
Role
Node を展開
RootVMを展開/監視
ComputeNode
RootVM
GuestVM
GuestVM
Guest Agent をｲﾝｽﾄｰﾙ
Guest VM を監視する
GuestAgent
GuestAgent
Fabric Agent
Windows AzureHypervisor
Windows AzureOS

ゲストOSテンプレートの種類
Web ロール/Worker ロール
OSの種類や修正プログラムの適用状況により複数のバージョンが用意されている
v1.x：Windows Server 2008 （英語版）
v2.x：Windows Server 2008 R2（英語版）
足りない機能はスタートアップタスクで読み込む
VM ロール
Webロール/Workerロールでは機能が足りない場合に、OS イメージを自分で作成

ロール
ゲストOS に与える役割
Web ロール－フロントWEBサービスに最適化されている
Worker ロール－バックエンドサービスに最適化されている
VM ロール－利用者によりカスタマイズが可能
Web ロール
Worker ロール
バックエンド
サービス
フロントエンド
Web サービス
xxx.cloudapp.net
Windows Azure ストレージ

ローカルストレージに関する考慮
ローカルストレージとはコンピュートサービスが持つ一時的な記憶領域のこと（厳密には C: ドライブのこと）
永続的ではない
MS都合（故障）で消える可能性がある
ストレージはフォールトトレラントではない
契約によって容量が異なる
20/225/490/1000/2048GB
ロールインスタンスごとに内容が異なる
あるインスタンスの処理結果を保存しても他のインスタンスからは見えない

永続ストレージ
残したいデータは永続ストレージに保存する
SQL Azure
REST API
http/https
ゲスト（仮想マシン）
Application
Windows Server
port 1433
IIS
Windows
Azure
Storage
TDS
SQL
Azure
ホスト（物理マシン）
Hyper-V
Server
Windows Azure

Guest VM を構成するドライブ
3 つの VHDファイルで構成されている
Guest VM を構成するストレージは非永続的である
Guest VM
構成情報
診断ログ
ページングファイル
ローカルストレージ
C:
VHD
D:
OS 本体
VHD
E:
パッケージファイル
VHD
Hyper-V
Server
Windows Azure

ホスト故障時の動作
パブリッククラウドは「ホスト故障」を前提に設計されている
新たなインスタンスが再展開される
ホストが故障
インスタンス（仮想マシン）
インスタンス（仮想マシン）
C:
C:
差分
新しいローカルストレージが再作成されるので、中身は消える
VHD
VHD
D:
D:
AVHD
AVHD
差分
VHD
VHD
E:
E:
AVHD
VHD
差分
VHD
Hyper-V
Hyper-V
Server
Server

性能に関する考慮
お金で「性能」は買えません！
スケールアップには限界がある
最大 CPU 8.16GHz*8 RAM14GB
永続ストレージの性能はオンプレミスに劣る（可能性がある）
ネットワーク越しのアクセス
ネットワーク的な距離が性能に大きく影響する
データセンターは世界に6か所（2011年6月現在）
アフィニティグループ、CDN の利用を考慮

Windows Azure VM のスケーラビリティ
価格は2011年5月現在
サブスクリプションあたり
最大20インスタンス
UP
OUT
インスタンス数

スケールアウトとスケールイン
負荷に応じてインスタンス数を調整できる
インスタンスの増減はユーザーに影響しない
ロール
インスタンス
Application
Application
Application
Application
Application
Application
Windows Server
Windows Server
Windows Server
Windows Server
Windows Server
Windows Server
IIS
IIS
IIS
IIS
IIS
IIS
xxx.cloudapp.net
WindowsAzure DataCenter

Windows Azure Storage へのアクセス
コンピュートノードとストレージノードは分離されている
Storage Node
Compute Node
Container
Guest OS
REST API
.NET
Application
Query
URL
操作
操作
Read/Write
有効時間
署名
SAK
config
SAK: Storage Account Key

サービスの展開場所は局所化する
ネットワーク的な遅延が性能に大きく影響する
WorkerRole
SQL Azure
WebRole
Amsterdam
North America
Chicago, Illinois
Dublin,
Ireland
Asia
Europe
Hong Kong
Azure Storage
Singapore
Africa
San Antonio, Texas
Central
andSouth America
Australia

アップデート/アップグレードに関する考慮
2種類のアップデート/アップグレード方法
In-PlaceUpgrade（自動/手動）
VIP Swap（手動のみ）
自動 In-PlaceUpgradeによりインスタンスは勝手に停止する
インスタンスを複数用意しておく※SLA 99.95% は2つ以上のインスタンスに担保されたもの
「手動」に変更することも可能
In-PlaceUpgrade は Update Domain 単位に処理される
自動/手動いずれにも適用される
一時的に新旧バージョンが混在する
プログラムをアップデートした場合には注意が必要
UpdateDomain あたり 15分

オンプレミスとの違い
オンプレミス（IaaS）
Application
Windows Azure（PaaS）
Windows Server
修正プログラム
Application
修正プログラム
Windows Server
Guest OS v1.3
Windows ServerGuest OS v1.4
Windows Server
Guest OS v1.2

Update Domain とは
一度にアップグレードするインスタンスの単位
Update Domain は規定で最大５個作成される
各インスタンスは順番に各Update Domainに所属する
Update Domain は手動で変更可能
（例）インスタンスが7個の場合
#0 から順番にアップグレード
Instance_0
Instance_5
UpgradeDomain#0
Instance_1
Instance_6
UpgradeDomain#1
Instance_2
UpgradeDomain#2
Instance_3
UpgradeDomain#3
Instance_4
UpgradeDomain#4

アップグレード～ Inｰplace Upgrade 方式
Update Domain 単位でアップデートする
利用者には影響を与えない
自動更新（パッチ適用）時にも同じ方式が適用される
Update Domain #0
アップデート
１
Update Domain #1
アップデート
2
新環境
アップデート
3
Update Domain #2
xxx.cloudapp.net
4
アップデート
Update Domain #3
5
アップデート
１
Update Domain #4
アップデート
Update Domain #0
Update Domain は最大5つ

In-Place Upgrade の様子
Update Domain#0 から
処理が開始される
Updating と表示されているが、サービスはアクセス可能

In-PlaceUpgrade の留意点
新環境と旧環境が異なる Update Domain に所属する場合、
新環境は下位互換を維持する必要がある
WebRole
WorkerRole
新しいメッセージフォーマットが旧環境の WorkerRole で認識できない
Azure StorageQueue
新
Update Domain #0
旧
Update Domain #1
旧
Update Domain #2

Update Domain
管理コンソールから参照できる

アップグレード～ VIP Swap 方式
ステージング環境とプロダクション環境の仮想IPを入れ替える
短時間で切り替え
容易なロールバック（やりなおし）
プロダクションとステージングのエンドポイント（HTTP/HTTPS）が同じでないとスワップできない
ロードバランサー
xxx.xxx.xxx.xxx
プロダクション
xxx.cloudapp.net
xxxx.hoge.net
ステージング
zzz.zzz.zzz.zzz

アップデート手法の制限について
※ 今後サポート予定

アップデートによるストレージへ影響
C:ドライブ以外は Re-Image によって差分が廃棄される
OSバージョンアップ
アプリケーション再展開
しばらく運用後
展開初期
C:
C:
C:
VHD
VHD
VHD
差分
差分
D:
D:
D:
新しいOSイメージ
E:
E:
E:
VHD
VHD
VHD
差分
新しいアプリイメージ
VHD
VHD
VHD
差分

ホストOSの障害/メンテナンスへの考慮
ホストOSにもメンテナンスは発生する
GuestVM の再起動
E: ドライブが再展開
In-place Upgrade
D:E: ドライブが再展開
ハードウェアは故障する可能性がある
Guest VM が別のハードウェアに再展開される
すべてのドライブが再展開
Fault Domain によるリスク分散

Fault Domain
物理的な障害の単位（≒ ラック）
ファブリックコントローラー
電源ユニット
スイッチ等
ハード障害がサービス全体に及ばないための機構
Windows Azure ファブリックは、ロールインスタンス群を最低 2つの異なる Fault Domainに分散配置する
ホストコンピューターのメンテナンス単位
緊急度の高い障害修正
緊急度の高いセキュリティパッチ
どの Fault Domain に所属するかは制御できない

ハードウェア障害の影響
Fault Domain
Cluster
Top of Rack Switches
Fabric Controller
Node
Node
Node
Node
Node
xxx.cloudapp.net
Node
Node
Node
Power Definition Unit
Rack
Rack
Rack
Rack

インスタンスの配置
Webロール 10個
Workerロール 7個
Upgrade Domain
UD#4
UD#0
UD#1
UD#2
UD#3
FD#0
Web#4
Web#6
Web#8
Web#2
Web#0
Woker#4
Woker#6
Woker#0
Woker#2
Fault Domain
FD#1
Web#1
Web#3
Web#7
Web#9
Web#5
Woker#1
Woker#3
Woker#5

ローカルストレージリセットのタイミング
Reboot と ReImage（再展開）はシステム管理者の指示以外でも発生する

管理/監視手法に関する考慮
Guest VM に対し、規定では従来の管理手法が一切使えない
リモートデスクトップ
WindowsPowerShell
管理機能を有効化できるのはサービス展開時
サービス定義ファイルに記述しておく
あとから有効化するには再展開/Update が必要
規定では”Admin”権限を持たない
「管理者へ昇格」が必要な操作が行えない
※スタートアップタスクにはAdmin権限がある
各種ログは永続ストレージに転送しないと消える可能性がある
診断モニタの設定が必要

管理/監視の対象と手法

リモートデスクトップでの環境変更はご法度
リモートデスクトプによる
環境変更は差分ディスクに書き込まれるため、消えてしまう可能性がある
ロール
リモートデスクトップ
ロールインスタンス
スケールアウトしても変更箇所は複製されないため、全てのロールインスタンスにログオンして環境変更を行う必要がある

Windows Azure VM
（ロールインスタンス）
Windows Azure VM
（ロールインスタンス）
WMI
WMI
管理
Windows Azure ｻﾌﾞｽｸﾘﾌﾟｼｮﾝ
Windows Azure Management API
管理
管理
Windows AzureConnect を使用
インスタンスの作成、再起動、停止、証明書の管理など
インスタンスの作成、再起動、停止、証明書の管理など
Windows Azure
Management
コマンドレット
標準装備の
コマンドレット
WindowsPowerShell
Windows Azure
管理ポータル（GUI）
WMI：Windows Management Instrumentation
Windows Azure の管理イメージ

各種ログに関する考慮
ログの収集は診断モニタを使用する
診断モニタの有効化は Visual Studio で行う
ロール単位に設定
有効化されていれば、設定変更はあとから行える
ログは Windows Azure ストレージに転送する
　※診断モニタが勝手に行う
ローカルストレージは消える可能性がある
Windows Azure ストレージは課金対象である

診断モニタ
ロールの診断モニタは必ず有効にしておく
主なログは診断モニタが自動収集
GuestVM（ロールインスタンス）
C: Drive
診断
モニタ
C:ResourcesDirectory
診断
モニタ
独自
IIS
独自のパス
独自のログ
オンプレミス

診断ログの種類
Windows Azure のログは診断モニタを介して収集する

診断モニタを有効にするには
Windows Azure ストレージアカウントを作成する
ストレージアカウント名
アクセスキー
パッケージの診断モニタ機能を有効化する
※ロール単位に実施

Windows Azure MMC
診断モニタの設定画面

Windows Azure MMC
診断ログの検索画面

診断モニタ関連のコマンドレット一覧

診断ログのキャッシュ容量について
OverallQuotaInMB
BufferQuotaInMB
DiagnosticInfrastructureLogs
Directories
BufferQuotaInMB
DirectoryQuotaInMB
DirectoryQuotaInMB
DirectoryQuotaInMB
Logs
BufferQuotaInMB
PerformanceCounters
BufferQuotaInMB
WindowsEcentLogs
BufferQuotaInMB

（参考）パフォーマンスカウンタの指定方法
これを指定する

（参考）イベントログのフィルタリング方法
ログの種類にコレを付加する

コストへの考慮
使用したリソースには課金される
Windows Azureコンピューティングの使用時間
Production/Stagingにかかわらずロールインスタンス単位に課金
不要なインスタンスは速攻で削除
Windows Azure ストレージの使用量
長期間残したいデータはオンプレミスに転送
Azure ストレージをバックアップ領域とは思わないこと
データセンター間のデータ転送量
可能な限りデータセンターを局所化する
SQL Azure のデータベース
契約容量によって金額が異なる
必要最小限のデータベースを契約
SE作業に必要だからといって使いすぎると大変なことに…

開発者との連携

開発者との連携が必要な項目
アーキテクチャの設計
管理と監視のための設定を埋め込んでもらう
パッケージファイルの受け渡し方法
Windows Azure ストレージ経由
バージョン管理も重要

アーキテクチャの設計
認証/認可方式について
可能な限り個人情報を保持しないアーキテクチャを実装
AD FS / AppFabric ACS の利用
永続ストレージの利用について
課金を強く意識した設計
Windows Azure ストレージへのアクセス方法
アクセスキーをハードコーディングしていないか？
SQL Azure へのアクセス方法
TDS(port 1433)or OData(http/s)
監視ポイント
※ 何かあった後ではログが消えている可能性がある
監視すべきパフォーマンスカウンタ
監視すべきイベントログ
テキストログの出力場所
動作環境
VM のサイズ（規定は Small）
OS のバージョン（規定は Windows Server 2008）
In-place Update の実行について（規定は Automatic）

認証/認可の方式について
Windows Azure Connect
アイデンティティ・フェデレーション
AD FS
AppFabric ACS

Windows Azure Connect
Role
Windows Azure Connect による仮想ネットワーク
インスタンス
インスタンス
Active Directory ドメイン
　　　　エンドポイント
　　　グループ
DC
SQL Server
File/PrintServer
DC

アイデンティティ・フェデレーション
アプリケーション
認可
認証
ACS
認証
ADFS
Active Directory

パッケージに埋め込んでもらう設定
管理/監視に必要な初期設定はパッケージファイルに埋め込む必要がある
サービス定義ファイル .csdef
ローカルストレージの定義
インポートするモジュールの指定
エンドポイントの定義
vmのサイズなど
プロジェクトファイル
各種設定
サービス構成ファイル .cscfg
ロールインスタンスの数
リモートデスクトップの有効化
Windows Azure Connect の有効化
ADドメイン参加
診断モニタの有効化
証明書の定義
OSのバージョンなど
コードや
画面定義等
スタートアップタスク
ファイルのコピー
ライブラリのインストール
レジストリの修正など
個別ファイル
インストーラーなど

まとめ

まとめ
IT Pro は
多くの場面でこれまでのコアとなる知識が生かせます
多くの場面でこれまでのオペーレションが通用しません
オペレーション
コアとなる知識
OSそのものの知識
高度な管理スキル
よろしくね
もっと会話を！
ラジャー

Windows Azure Platform 運用設計 V1.1

by Junichi Anno on Jun 16, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

Windows Azure Platform 運用設計 V1.1 — Presentation Transcript