1

日本マイクロソフト株式会社

エバンジェリスト

安納 順一http://blogs.technet.com/junichia/

twitter @junichia

Windows Azure Platform 運用設計第 1.1 版

2011 年 6 月 27 日

2

本セッションの内容

Windows Azure と Windows Server との違いを理解し、 IT インフラの一部として Windows Azure を使用する場合に IT Pro が認識しておかなければならない運用設計の留意点について理解しましょう。

• 運用設計の留意点• （運用に支障をきたさないための）

開発者との連携ポイント

3

Agenda

1. はじめに2. 運用設計の留意点

サービス展開に関する考慮 ローカルストレージに関する考慮 性能に関する考慮 アップデート / アップグレードに関する考慮 ホスト OS の障害 / メンテナンスに関する考慮 管理 / 監視の手法に関する考慮 各種ログに関する考慮 コストに関する考慮

3. 開発者との連携ポイント

4

はじめに

5

IT Pro にとっての　 Windows Azure Platform とは？

• うまい話なんてあるはずない• 使える新機能があれば導入する• お客様への「提案映え」も重要

• Windows Server と同様に管理できるのか？• PaaS とか IaaS とかはどうでもよい• 新しい管理手法なんて覚えたくない

• SE Service で儲けられるか？• SE 作業は無くなる？• 作業の質や内容が変わる？

単なるインフラ選択肢の 1 つ

6

IT Pro の責任範囲

サービスの展開

管理 / 監視

Drives

Memory

OS Patches

Networking

Physical Hardware

アーキテクチャの検討

この部分のコストが意外と高い

IT Pro の責任範囲

7

作業内容の変化

IT Pro の責任範囲

Drives

Memory

OS Patches

Networking

Physical Hardware

Cloud の責任範囲

アーキテクチャの検討

サービスの展開

管理 / 監視

増

減

減

8

IT Pro に求められる作業

• 運用のベストプラクティス確立– アンチパターンの蓄積– クラウドベンダーごとの性格付け

• テクノロジー検証– 相互連携（クラウド間、クラウドーオンプレミス間）– 他社連携

• パフォーマンス予測– どのタイミングでインスタンスを増減するか– コストにも大きく影響

• ランニングコスト予測– 運用プロセスと密接に関係する

• 開発者との情報交換

9

運用時の留意点

10

Windows Azure Platform の位置づけ

11

Windows Server との違い

  Windows Server Platform Windows Azure Platform

OS Windows Server Windows Azure

DBMS SQL Server SQL Azure

ハードウェア構成 顧客が指定する マイクロソフトが指定する

OS や DBMS の更新 顧客が更新する マイクロソフトが更新する

（顧客による手動更新も可能）

購入方法 サーバーとライセンスを購入 サブスクリプションの購入

アプリケーションプラット

フォーム

.NET Framework, Java, php, AppFabric など

開発ツール Visual Studio

管理と監視 System Center 、 PowerShell など

認証およびアクセス管理 Active Directory Domain Service

Active Directory Federation Service

Windows Azure AppFabric ACS

ハイパーバイザー Hyper-V

12

サービス展開に関する考慮【大原則】

• OS は自分でインストールできない※ VM ロールで回避可能

• サービス展開後の環境変更は“消える”可能性がある• 環境を作り直して再展開する必要がある

• 機能の追加 / 変更はコマンドベース（スタートアップタスク）で実行

• 作業のやり直しは 15 分以上のロスを発生• 開発者との綿密な連携が必須（後述）

• OS に対する”管理者”権限は無い※ ADMINモードで回避可能

13

サービス展開に関する考慮

Server （ H/W ）

Windows Server

IIS

Server （ H/W ）

Application

Windows Server

IIS

Server （ H/W ）

Windows Server （ IaaS ）の場合

Windows Azure （ PaaS ）の場合

PaaS なので、 OS をインストールするというプロセスが存在しない

サービスを作成

「サービスの URL 」が

DNS に登録される

手動

手動

手動

Windows Server

Application

IIS

Server （ H/W ）

アプリケーションを展開

自動

手動

Hyper-V

14

Fabric Controller

Node

Node Node Node Node

Node Node Node Node

Node Node Node Node Node

Node Node Node Node Node

雲の中はこうなってる

15

Windows Azure Platform ～ Node の展開

Fabric Controller

Image Store

Windows Azure OS

MaintenanceOS

WebRole

WorkerRole

Node

Node

Node 用の OSPXE Boot 用

OS

展開・監視

Node Node

NodeNode

16

Windows Azure Platform ～ ゲストの展開

Fabric Controller

Compute Node

Image Store

Windows Azure OS

Maintenance

OS

WebRole

WorkerRole

ゲスト OS に使用される

ゲスト OS に使用される

テンプレート

Windows Azure Hypervisor

Windows Azure OS

Root VM

Fabric Agent

Guest VMGuest VM

Guest Agent

• Guest Agent をｲﾝｽﾄｰﾙ• Guest VM を監視する

• Node を展開• Root VM を展開 / 監

視

Guest Agent

17

ゲスト OS テンプレートの種類

• Web ロール /Worker ロール• OS の種類や修正プログラムの適用状況により複数の

バージョンが用意されている– v1.x：Windows Server 2008 （英語版）– v2.x：Windows Server 2008 R2 （英語版）

• 足りない機能はスタートアップタスクで読み込む

• VM ロール• Web ロール /Worker ロールでは機能が足りない場

合に、 OS イメージを自分で作成

18

ロール

フロントエンドWeb サービス

xxx.c

lou

dap

p.n

et

バックエンドサービス

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

Web ロール Worker ロール

Windows Azure ストレージ

19

ローカルストレージに関する考慮

• 永続的ではない– MS都合（故障）で消える可能性がある

• ストレージはフォールトトレラントではない• 契約によって容量が異なる

– 20/225/490/1000/2048 GB

• ロールインスタンスごとに内容が異なる– あるインスタンスの処理結果を保存しても他のインスタンスか

らは見えない

ローカルストレージとはコンピュートサービスが持つ一時的な記憶領域のこと（厳密には C: ドライブ のこと）

20

永続ストレージ

• 残したいデータは永続ストレージに保存する– Windows Azure ストレージ– SQL Azure

ゲスト（仮想マシン）

Windows Server

Application

IIS

Server

Hyper-V

ホスト（物理マシン）

Windows Azure

Windows Azure

Storage

SQLAzure

port 1433

http/https

REST API

TDS

21

Guest VM を構成するドライブ• 3 つの VHD ファイルで構成されている• Guest VM を構成するストレージは 非永続的である

Guest VM

E:VHD

C:VHD

D:VHD

• 構成情報• 診断ログ• ページングファイル• ローカルストレージ

• OS 本体

• パッケージファイル

Server

Hyper-V

ホスト（物理マシン）

Windows Azure

22

AVHD

E:

D:

ホスト故障時の動作

インスタンス（仮想マシン）

Server

Hyper-V

ホスト（物理マシン）

C:VHD

VHD

VHD

差分

AVHD

AVHD差分

差分

E:

D:

インスタンス（仮想マシン）

C:

VHD

VHD

VHD

Server

Hyper-V

ホスト（物理マシン）

新たなインスタンスが再展開される

ホストが故障

新しいローカルストレージが再作成されるので、中身は消える

新しいローカルストレージが再作成されるので、中身は消える

新しいローカルストレージが再作成されるので、中身は消える

パブリッククラウドは「ホスト故障」を前提に設計されている

23

性能に関する考慮

• スケールアップには限界がある– 最大 CPU 8.16GHz*8 RAM 14GB

• 永続ストレージの性能はオンプレミスに劣る（可能性がある）– ネットワーク越しのアクセス

• ネットワーク的な距離が性能に大きく影響する– データセンターは世界に 6 か所（ 2011 年 6 月現在）– アフィニティグループ、 CDN の利用を考慮

お金で「性能」は買えません！

24

ExtraLarge

Large

Medium

Small

ExtraSmall

ExtraLarge

Large

Medium

Small

ExtraSmall

ExtraLarge

Large

Medium

Small

ExtraSmall

Windows Azure VM のスケーラビリティ

インスタンス数

UP

OUT

サブスクリプションあたり最大 20 インスタンス

価格は 2011 年 5 月現在

25

スケールアウトとスケールイン• 負荷に応じてインスタンス数を調整できる• インスタンスの増減はユーザーに影響しない

Windows Server

Application

IIS

Windows Server

Application

IIS

Windows Server

Application

IIS

Windows Server

Application

IIS

Windows Server

Application

IIS

Windows Azure Data Center

ロールインスタンス

xxx.c

lou

dap

p.n

et

Windows Server

Application

IIS

26

Windows Azure Storage へのアクセス

Storage Node

Con

tain

er

Compute NodeGuest OS

Application

config

RE

ST A

PI

SAK

Query

URL

Read/Write

有効時間

.NE

T

操作 操作

署名

SAK: Storage Account Key

コンピュートノードとストレージノードは分離されている

27

サービスの展開場所は局所化する

Central and

South America

Europe Asia

Africa

Australia

North America

San Antonio, Texas

Chicago, Illinois Dublin,

Ireland

Amsterdam

Singapore

Hong Kong

WebRole

WorkerRoleSQL Azure

Azure Storage

ネットワーク的な遅延が性能に大きく影響する

28

アップデート / アップグレードに関する考慮• 2 種類のアップデート / アップグレード方法

– In-Place Upgrade （自動 / 手動）– VIP Swap （手動のみ）

• 自動 In-Place Upgrade によりインスタンスは勝手に停止する– インスタンスを複数用意しておく※ SLA 99.95 % は 2 つ以上のインスタンスに担保されたもの

– 「手動」に変更することも可能

• In-Place Upgrade は Update Domain 単位に処理される– 自動 / 手動 いずれにも適用される– 一時的に新旧バージョンが混在する

• プログラムをアップデートした場合には注意が必要– Update Domain あたり 15 分

29

オンプレミスとの違い

Windows Server

Application

修正プログラム

修正プログラム

Windows ServerGuest OS v1.4

Windows Server Guest OS v1.3

Windows Server Guest OS v1.2

Application

オンプレミス（ IaaS ）

Windows Azure （ PaaS ）

30

Update Domain とは• 一度にアップグレードするインスタンスの単位• Update Domain は規定で最大５個作成される• 各インスタンスは順番に各 Update Domain に所属する• Update Domain は手動で変更可能

Instance_0

Instance_1

Instance_2

Instance_3

Instance_4

Instance_5

Instance_6

UpgradeDomain#0

UpgradeDomain#1

UpgradeDomain#2

UpgradeDomain#3

UpgradeDomain#4

#0 から

順番

にア

ップ

グレ

ード

（例）インスタンスが 7個の場合

31

アップグレード ～ In ｰ place Upgrade 方式• Update Domain 単位でアップデートする• 利用者には影響を与えない• 自動更新（パッチ適用）時にも同じ方式が適用される

xxx.c

lou

dap

p.n

et

Update Domain #0

Update Domain #1

Update Domain #2

Update Domain #3

Update Domain #4

Update Domain #0

Update Domain は最大 5 つ

新環境

アップデート

アップデート

１

１

アップデート 2

アップデート 3

アップデート 4

アップデート 5

32

In-Place Upgrade の様子

Update Domain#0 から処理が開始される

Updating と表示されているが、サービスはアクセス可能

33

In-Place Upgrade の留意点新環境と旧環境が異なる Update Domain に所属する場合、新環境は下位互換を維持する必要がある

Update Domain #0

Update Domain #1

Update Domain #2

Web Role Worker Role

新

旧

旧

新しいメッセージフォーマットが旧環境の Worker Role で認識できない

Azure Storage Queue

34

Update Domain

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

35

アップグレード ～ VIP Swap 方式• ステージング環境とプロダクション環境の仮想 IP を入れ替える• 短時間で切り替え• 容易なロールバック（やりなおし）

xxx.c

lou

dap

p.n

et

xxxx.h

og

e.n

et

xxx.x

xx.x

xx.x

xx

zzz.

zzz.

zzz.

zzz

プロ

ダク

ショ

ンス

テー

ジン

グ

プロダクションとステージングのエンドポイント（ HTTP/HTTPS ）が同じでないとスワップできないロードバランサー

36

アップデート手法の制限について

操作 .cspkd.cscfg

.csdefIn-placeupgrade

Staged (VIP swap)

削除してから再展開

OS バージョンを変更 ○ ○ ○ ○

.NET 信頼レベルを変更 ○ × （※） ○ ○

VM サイズを変更 ○ × （※） ○ ○

ローカルストレージを変更 ○ △（増のみ）

○ ○

ロールの追加 /削除 ○ × （※） ○ ○

サービスのエンドポイントを追加 /削除 ○ × （※） × ○

ロールインスタンスの追加 /削除 ○ ○ ○ ○

<configurationsettings> （値と名前）の変更 ○ × （※） ○ ○

<configurationsettings> （値のみ）の変更 ○ ○ ○ ○

新しい証明書の追加 ○ ○ × （※） ○ ○

証明書の変更 ○ ○ ○ ○

コードの変更 ○ ○ ○ ○

※ 今後サポート予定

37

アップデートによるストレージへ影響C: ドライブ以外は Re-Image によって差分が廃棄される

差分

差分

差分

C:

D:

E:

D:

E:

C:

差分

D:

E:

C:

展開初期 しばらく運用後

OS バージョンアップアプリケーション再展開

VHD

VHD

VHD

VHD

VHD

VHD

VHD

VHD

VHD

新しい OSイメージ

新しいアプリイメージ

38

ホスト OS の障害 / メンテナンスへの考慮

• ホスト OS にもメンテナンスは発生する– Guest VM の再起動

• E: ドライブが再展開– In-place Upgrade

• D: E: ドライブが再展開

• ハードウェアは故障する可能性がある– Guest VM が別のハードウェアに再展開される

• すべてのドライブが再展開

• Fault Domain によるリスク分散

39

Fault Domain

• 物理的な障害の単位（≒ ラック） ファブリック コントローラー 電源ユニット スイッチ 等

• ハード障害がサービス全体に及ばないための機構 Windows Azure ファブリックは、ロールインスタンス群

を最低 2 つの異なる Fault Domain に分散配置する

• ホストコンピューターのメンテナンス単位 緊急度の高い障害修正 緊急度の高いセキュリティパッチ

• どの Fault Domain に所属するかは制御できない

40

ハードウェア障害の影響

Rack

Fabric Controller

Power Definition Unit

Top of Rack Switches

Node

Node

Node

Node

Node

Node

Node

Node

Rack Rack Rack

Cluster

Fault Domain

xxx.c

lou

dap

p.n

et

41

インスタンスの配置

Upgrade Domain

UD#0 UD#1 UD#2 UD#3 UD#4

FD#0

FD#1

Web#0

Web#1

Web#2

Web#3

Web#4

Web#5

Web#6

Web#7

Web#8

Web#9

Woker#0

Woker#1

Woker#2

Woker#3

Woker#4

Woker#5

Woker#6

Fault

Dom

ain

Web ロール 10 個Worker ロール 7 個

42

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

操作の主体 アクション 発生する動作 C: D: E: 備考

管理者 RDS で Restart ー 変わらず 変わらず 変わらず

管理者 「停止」してから「起動」 Reboot 変わらず 変わらず リセット VM ロールには E ドライブは無い

管理者 Reboot したとき Reboot 変わらず 変わらず リセット VM ロールには E ドライブは無い

管理者 Re-Image したとき Re-Image 変わらず リセット リセット 　

管理者 ロールを削除してから展開 ー リセット リセット リセット 初期展開と同じ

AzureOS バージョンの自動アップグレード Re-Image 変わらず リセット リセット 　

管理者OS バージョンの手動アップグレード Re-Image 変わらず リセット リセット 　

管理者 OS バージョンのロールバック Re-Image 変わらず リセット リセット 　

管理者 インスタンスを増やす Re-Image リセット リセット リセット

増えたインスタンスに対して。

既存インスタンスには影響なし

管理者 インスタンスを減らす ー 変わらず 変わらず 変わらず 　

Azure ホスト OS がアップグレード Re-Image Reboot

変わらず変わらず

変わらずリセット

リセットリセット

　

Azure

ホスト OS またはハードウェア障害により、別のサーバーにサービスを移転する必要性が生じたとき

Re ｰ Image + ﾛｰｶﾙｽﾄﾚｰｼﾞﾘｾｯﾄ リセット リセット リセット

移動対象となったインスタンスに対して。その他のインスタンスには影響はない。

43

管理 / 監視手法に関する考慮

• Guest VM に対し、規定では従来の管理手法が一切使えない– リモートデスクトップ– Windows PowerShell

• 管理機能を有効化できるのはサービス展開時– サービス定義ファイルに記述しておく– あとから有効化するには再展開 /Update が必要

• 規定では” Admin”権限を持たない– 「管理者へ昇格」が必要な操作が行えない※スタートアップタスクには Admin権限がある

• 各種ログは永続ストレージに転送しないと消える可能性がある– 診断モニタの設定が必要

44

管理 / 監視 の対象と手法

対象 管理 / 監視項目 手法サブスクリプション • ホストサービスの作成と展開

• ホストサービスの再起動• Guest VM サイズの変更• インスタンス数の調整• ストレージアカウントの作成 /削除• 不要なロール、データベース、ネームスペースの削除

• OS バージョン / レベルの変更• サービス証明書 / 管理証明書 の管

理

• 管理ポータル• PowerShell コマンド

レット

Guest VM • 各種管理操作 • リモートデスクトップ• PowerShell on Windows

Azure Connect

• パフォーマンスログ• イベントログ• クラッシュダンプ• その他ログ（ IIS 等）

• 診断モニタ

• ランタイムモジュール / 必須ソフトウェアの組み込み

• スタートアップタスク• VM ロール

アプリケーション • パフォーマンスログ• アプリケーションのログ

• 診断モニタ

45

リモートデスクトップでの環境変更はご法度

ロールインスタンス

ロールインスタンスリモートデスクトップ

リモートデスクトプによる環境変更は差分ディスクに書き込まれるため、消えてしまう可能性がある

ロールインスタンス

ロールインスタンス

スケールアウトしても変更箇所は複製されないため、全てのロールインスタンスにログオンして環境変更を行う必要がある

スケールアウトしても変更箇所は複製されないため、全てのロールインスタンスにログオンして環境変更を行う必要がある

スケールアウトしても変更箇所は複製されないため、全てのロールインスタンスにログオンして環境変更を行う必要がある

ロール

46

Windows Azure VM（ロールインスタンス）

Windows Azure ｻﾌﾞｽｸﾘﾌﾟｼｮﾝ

Windows Azure VM（ロールインスタンス）

Windows PowerShell

WMIWMI

Windows Azure Management API

Windows Azure Management コマンドレット

標準装備のコマンドレット

管理 インスタンスの作

成、再起動、停止、証明書の管理 など

Windows Azure 管理ポータル（ GUI ）

管理

Windows Azure Connect を使用

管理

インスタンスの作成、再起動、停止、証明書の管理 など

WMI：Windows Management Instrumentation

Windows Azure の管理イメージ

47

各種ログに関する考慮

• ログの収集は診断モニタを使用する

• 診断モニタの有効化は Visual Studio で行う• ロール単位に設定• 有効化されていれば、設定変更はあとから行える

• ログは Windows Azure ストレージに転送する　※診断モニタが勝手に行う

• ローカルストレージは消える可能性がある• Windows Azure ストレージは課金対象である

48

診断モニタ• ロールの診断モニタは必ず有効にしておく• 主なログは診断モニタが自動収集

Guest VM （ロールインスタンス）

C: Drive

IIS

診断モニタ

診断モニタ

C:\Resources\Directory

独自

独自のパス

Windows Azure ストレージ

独自のログオンプレミス

49

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

ログのタイプ ログの内容 設定用コマンドレット

DiagnosticInfrastructureLogs 診断モニタ自身のログ。診断モニタの動作

確認、トラブルシューティングに利用する

Set-InfrastructureLog

Logs 診断モニタの各種設定（ローカルストレー

ジのサイズや転送のタイミングなど）が書

かれたログ

Set-WindowsAzureLog

Directories 指定したディレクトリ配下のファイル

（ IIS のアクセスログや独自のテキストロ

グなど）

Set-FileBasedLog

PerformanceCounters パフォーマンスモニターのカウンターを元

に収集されたログ

Set-PerformanceCounter

WindowsEventLogs イベントログ Set-WindowsEventLog

50

診断モニタを有効にするには

1. Windows Azure ストレージアカウントを作成する• ストレージアカウント名• アクセスキー

2. パッケージの診断モニタ機能を有効化する※ロール単位に実施

51

52

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

53

Windows Azure MMC

診断ログの検索画面

54

診断モニタ関連のコマンドレット一覧Get-ActiveTransfers インスタンス単位に、有効な診断ログ転送に関する設定

を取得するGet-CommonConfigurationLogs インスタンス単位に、診断ログ共通のバッファ容量およ

び、診断ログの設定変更をポーリングする間隔を取得する。

Get-DiagnosticAwareRoleInstances

指定したロールの中で診断モニタが正常に動作しているロールインスタンスを出力する。

Get-DiagnosticAwareRoles 診断モニタが有効なロールの一覧を出力するGet-DiagnosticConfiguration 各種診断ログの設定情報を出力するSet-CommonConfigurationLogs 診断ログ共通ののバッファ容量および転送間隔を設定す

る。インスタンス ID を指定すれば、インスタンス単位に異なる値を設定することができる。

Set-FileBasedLog Directory タイプのログに関する設定を行うSet-InfrastructureLog DiagnosticInfrastructureLogs タイプのログに関する

設定を行うSet-PerformanceCounter PerformanceCounters タイプのログに関する設定を行

うSet-WindowsAzureLog Logs タイプのログに関する設定を行うSet-WindowsEventLog WindowsEventLogs タイプのログに関する設定を行う

Start-OnDemandTransfer 指定した診断ログのオンデマンド転送を開始するStop-ActiveTransfer アクティブなオンデマンド転送を停止する

55

診断ログのキャッシュ容量について

Directories

DirectoryQuotaInMB

Logs

BufferQuotaInMB

DirectoryQuotaInMB

PerformanceCounters

BufferQuotaInMB

BufferQuotaInMB

WindowsEcentLogs

BufferQuotaInMB

BufferQuotaInMB

OverallQuotaInMB

DiagnosticInfrastructureLogs

DirectoryQuotaInMB

56

（参考）パフォーマンスカウンタの指定方法

これを指定する

010203

0405

$ObjectType = "Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration"$rate = [TimeSpan]::FromSeconds(60)$CDriveFreeSpace = New-Object $ObjectType -Property @{CounterSpecifier='\LogicalDisk(C:)\Free Megabytes'; SampleRate=$rate }$config.DataSources.Add($ CDriveFreeSpace ) Set-PerformanceCounter -PerformanceCounters $config.DataSources -RoleName $Role-BufferQuotaInMB 1024 -TransferPeriod 10 -StorageAccountName $storage -StorageAccountKey $key -DeploymentId $deployid

57

（参考）イベントログのフィルタリング方法

ログの種類にコレを付加する

58

コストへの考慮

• Windows Azure コンピューティングの使用時間 Production/Staging にかかわらずロールインスタンス単位

に課金 不要なインスタンスは速攻で削除

• Windows Azure ストレージの使用量 長期間残したいデータはオンプレミスに転送 Azure ストレージをバックアップ領域とは思わないこと

• データセンター間のデータ転送量 可能な限りデータセンターを局所化する

• SQL Azure のデータベース 契約容量によって金額が異なる 必要最小限のデータベースを契約

SE 作業に必要だからといって使いすぎると大変なことに…

使用したリソースには課金される

59

開発者との連携

60

開発者との連携が必要な項目

• アーキテクチャの設計

• 管理と監視のための設定を埋め込んでもらう

• パッケージファイルの受け渡し方法 Windows Azure ストレージ経由 バージョン管理も重要

61

アーキテクチャの設計 認証 / 認可方式について

• 可能な限り個人情報を保持しないアーキテクチャを実装• 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 ）

62

認証 / 認可の方式について

• Windows Azure Connect• アイデンティティ・フェデレーション

• AD FS• AppFabric ACS

方式 導入の容易さ

プログラムの改編

Active Directory との連携

ソーシャルネットワーク等外部ＩｄＰとの連携

Windows Azure Connect

◎ 基本的に必要なし

◎ ×

AD FS ○ クレームベースの認可を行うように変更する必要がある

◎ △ できなくはないがアプリケーションが外部 IdP 依存になってしまう

AppFabric ACS

○ クレームベースの認可を行うように変更する必要がある

◎ ◎

63

Windows Azure Connect

　　　　エンドポイント　　　グループ

Active Directory ドメイン

Role

インスタンス インスタンス

DC DC SQL Server File/Print Server

Windows Azure Connect による 仮想ネットワーク

64

アイデンティティ・フェデレーション

Active Directory

認証

認可アプリケーション認証

AD FS

ACS

65

パッケージに埋め込んでもらう設定

• 管理 / 監視 に必要な初期設定はパッケージファイルに埋め込む必要がある

プロジェクトファイル

サービス定義ファイル .csdef• ローカルストレージの定義• インポートするモジュールの指定• エンドポイントの定義• vm のサイズ など

スタートアップタスク• ファイルのコピー• ライブラリのインストール• レジストリの修正 など

個別ファイル• インストーラーなど

サービス構成ファイル .cscfg• ロールインスタンスの数• リモートデスクトップの有効化• Windows Azure Connect の有効化

AD ドメイン参加• 診断モニタの有効化• 証明書の定義• OS のバージョン など

コードや画面定義等

各種設定

66

まとめ

67

まとめ

IT Pro は• 多くの場面でこれまでのコアとなる知識が生かせます• 多くの場面でこれまでのオペーレションが通用しません

コアとなる知識

オペレーション

OS そのものの知識高度な管理スキル

もっと会話を！ ラジャー

よろしくね

68