• Microsoft Azure の IaaS (Infrastructure as a Service)
• わずか数分で Azure データセンターで仮想サーバーが起動
• 使った分だけ、分単位の従量課金
• Windows も Linux も
Soon Soon New New
• シリーズごとに1コアあたりの性能は異なる。
• ACU (Azure Computing Unit) をチェックする。
 Standard A1を100としたときの相対的な性能。
• 常に同時に3つのディスクへデータが書き込まれる。
• 最大で同時に2つのディスクが壊れても、データ損失なく稼働する。
VHD
ファイル
• ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセ
ンターにも非同期で複製される。
• 複製元での3重化+複製先での3重化=合計6重化。
> 500 miles
東日本 西日本
Blob ストレージBlob ストレージ
• GRS はストレージをペアリージョンに非同期で複製する。
• GRS の複製時にはOS 内での整合性は考慮されない。
• 複数のディスクがある場合、各ディスクが異なるタイミングで複製
されうる。
 記憶域スペースや LVM を使っている場合、不整合が生じうる。
• GRS のフェールオーバーはマイクロソフトの判断により実行される。
 利用者任意のタイミングでのフェールオーバーはできない。
災害時の業務継続が目的であれば、別の手段も検討する。
• 所有しているリソースに影響を及ぼしうる Azure 上の問題について、
情報や解決策を提供する。
 自分の所有しているリソースに影響のない問題は表示されない。
 Azure ポータル上のアイコンから参照できる。
• Azure 仮想マシンでは原則としてディスク共有型のクラスタを構成
できない。
 とくにファイルサーバーやDBサーバーにおいて要注意
• RDMBS の機能や3rd パーティのソリューションを利用した、ディ
スクを共有しない冗長化構成を考える。
〇 Azureではこちらを利用する× Azureでは原則として利用できない
• Windows Server 2016 の機能である S2D (Storage Space
Direct : 記憶域スペースダイレクト)を使い、Azure 仮想マシンで
SQL Server AlwaysOn フェールオーバークラスターを構成できる。
• ただし S2D を使えばあらゆるワークロードでディスク共有型クラスタが構成できるわけではない。利用
しているワークロードが共有ディスクとして S2D の構成をサポートしているか確認が必要。
• Azure 仮想マシンを複数台構成
にするときは、可用性セットを
定義する。
• これにより、1つのラックの障
害で2台の仮想マシンが同時に
停止することを回避できる。
• 可用性セット自体にクラスタリ
ング・負荷分散・データ複製な
どの機能があるわけではないの
で注意すること。
障害ドメイン 障害ドメイン障害ドメイン
ラック
FC
・
・
・
・
・
・
ルータ
ラック
FC
・
・
・
・
・
・
ルータ
ラック
FC
・
・
・
・
・
・
ルータ
可用性セット
“AS1”
• 障害ドメイン (FD)
 同時に物理障害が起こりう
る単位 ≒ ラック
• 更新ドメイン (UD)
 同時にメンテナンスを行う
単位
• 2017年2月にGAした仮想マシンの新しいディスク形式。
• いろいろなメリットがあるが、
 ストレージアカウントの作成・管理が不要に
 スナップショット、仮想マシンイメージの容易な作成
 Blobとしてのエンドポイントが無い
• 実は Managed Disk では可用性も向上している!
 可用性セットに含まれる仮想マシンのManaged Diskは
自動的に異なる障害ドメインに配置される。
 可用性セットを構成する場合は、Managed Disk を使
うことを強く推奨!
• 「理由はよくわからないけど何か調子が悪い」というときに実行し
てみるとよい(かもしれない)
• Azure 仮想マシンのディスクをまるごとバックアップ
• 稼働中にオンラインでバックアップ取得可能
• Windows にも Linux にも対応
• Azure ポータルの仮想マシン設定画面から、
簡単に構成・操作できる
• 主要なAzure Backupの利用形態として以下の3種類がある。
1. Azure 仮想マシンのバックアップ
2. オンプレミスの仮想マシンやDBのバックアップ
3. ファイルやフォルダのバックアップ
今日お話しするのはこれ
Azure
Backup
• Windows では VSS を利用したアプリケーション整合性バックアッ
プが取得できる。
 SQL Server などの VSS に対応したアプリケーションであれば、アプリ
ケーションのレベルで静止点を取って、バックアップを行う。
• Linux でもユーザーが独自にバックアップ事前・事後スクリプトを
設定することにより、アプリケーション整合性バックアップを取得
することができる。(プレビュー)
 VM 内にスクリプトを配置しておくと、バックアップ事前・事後にそれが自
動的に実行される。
 スクリプトが無い、もしくは失敗した場合でも、ファイルシステム整合性
バックアップが実行される。
1. 仮想マシン全体のリストア
 Managed Disk の仮想マシンであれば、そのままManaged Diskの仮想マ
シンとしてリストアされる。
2. ディスクのストレージアカウントへの復元
 復元したディスクの利用方法にもいくつかのパターンがある
1. ARMテンプレートを使って復元したディスクから新規仮想マシンを作成
2. 復元したディスクを既存の仮想マシンに接続
3. PowerShellを使って復元したディスクから新規仮想マシンを作成
• Azure Backup は現時点で以下をサポートしない。
 1TB よりも大きなディスク
 つまり 4TBディスクは未サポート
 16本よりも多くのディスクを接続した仮想マシン
 存在している仮想マシンの上書きリストア
 まず仮想マシンを削除してからリストアする必要がある
• いずれも将来的にはサポートされる予定。
• 仮想マシン全体ではなく、特定のファイルやフォルダだけをリスト
アする機能もある。(プレビュー機能)
• 過去時点のディスクがiSCSI ディスクとして仮想マシンに接続され、
そこから必要なファイル・フォルダを取り出すことができる。
Azure Backup
iSCSI ディスクとして接続
• Azure Backup では稼働中のオンラインバックアップが可能だが、
バックアップ取得は業務ピーク時を外すこと。
 バックアップ取得時にはストレージアカウントに対して大量のアクセスが発
生し、業務に影響を及ぼす可能性がある。
• 多数の仮想マシン/ディスクを1つのストレージアカウントに詰め込
みすぎないようにする。
• 特にバックアップ・リストアの性能が重要な仮想マシンについては、
Premium Storage の利用を検討する。
• ジオ冗長ストレージ(GRS)により、バックアップデータを別リー
ジョンに複製することもできる。
Azure
Backup
• GRS 同様、 Azure Backup サービス自体のフェールオーバーもマ
イクロソフトの判断で実施される。
災害時の早期業務再開のためには、ASR が適切な選択肢。
• Azure 仮想マシンのデータを、常に別のAzure データセンターに
同期する。
• 大規模災害で Azure データセンターが被災したときに、複製され
たデータをもとに別の Azure データセンターで仮想マシンを起動
し、業務を再開できる。
• 料金は2,550+ストレージ料金のみ。
DR 用仮想マシンの料金が発生するの
は、フェールオーバー先で仮想マシン
を起動したときのみ。
• Azure Site Recovery には以下の2種類がある。
1. オンプレミスから Azure への DR
2. 2つの Azure データセンター間での DR (プレビュー)
今日お話しするのはこれ
• VM内で動作するエージェントが、同一リージョンのキャッシュスト
レージに変更データを書き込む。
• キャッシュストレージから複製先リージョンにデータが複製される。
• フェールオバー後に
仮想マシンが正しく
起動するか、事前に
テストしておくこと
が重要。
• 複製元仮想マシンを
稼働させたまま、テ
ストを実行できる。
• 一般的にフェールオーバー手順は複雑に
なりがち。
 手順書を見ながら実行しても、ミスする可
能性がある。
• 複数の仮想マシンからなる複雑なシステ
ムのフェールオーバー処理を、復旧計画
として定義できる。
 仮想マシン起動の順序や、Azure
Automation Runbook の実行などを定義し
ておく。
 フェールオーバーの際は、この復旧計画を
実行すればよい。
• ASR はディスクイメージ全体を非同期で複製する。
 Active Directoryドメインコントローラーでは、データの不整合が発生する
可能性がある。
• 原則として、Active Directoryドメインコントローラーには ASR を
利用しない。
Active Directory
によるデータ複製
Azure Site Recovery
• 1TB を超えるディスクはサポートされない。
 これは Azure リージョン間での ASRについての制約。オンプレミスから
Azure への ASR では、4TB ディスクがサポートされた。
• Managed Disk はサポートされない。
• 以下の構成については、フェールオーバー時に復旧計画から自動化
スクリプトを実行して構成する必要がある。
 ロードバランサー(内部・外部ともに) / Traffic Manager
 Network Security Group (NSG) など
• ASR ではフェールオーバー時にIP アドレス体系を保持することも
変更することも、どちらも可能。
 IPアドレス体系を保持する場合、オンプレミスを含めたルーティングやIPア
ドレスのバッティングの回避などについての考慮が必要。
 IPアドレス体系を変更する場合、アプリの正常動作について確認が必要。
10.3.0.0/1610.2.0.0/16
IPアドレス
体系重複のため
同時接続はNG
IPアドレスが変わっても
正常に動作するか?
IPアドレス体系を保持しないIPアドレス体系を保持する
• 社内 WAN からAzure 東日本リージョンへ ExpressRoute で接続していた。
• 災害が発生、ASR で西日本リージョンへフェールオーバーした。
• 社内 WAN から西日本リージョンへどう接続する?
1. あらかじめ西日本リージョンへも ExpressRoute を引いておく。
 災害対策用であれば従量課金がおすすめ。
2. Site-to-Site VPN 接続する。
 例えば、関西の業務拠点にVPN装置を配置しておき、フェールオーバー時に接続する。
3. 例外的にインターネット経由での接続を許可する。
 大規模災害時には社外からのアクセスに対するニーズが高まると予想される。
• 仮想マシンのディスク(ストレージ)暗号化には2つの種類がある。
 仕組みや目的が異なる。併用も可能。
1. Azure Disk Encryption
 BitLocker(Windows) および DM-Crypt(Linux)
 暗号化キーは Azure Key Vault で管理
 ポータルからVHDをダウンロードしても暗号化状態が保たれる
2. Storage Service Encryption
 Azure ストレージの機能で、データ保存時に暗号化、データ取得時に複合化
 ポータルからVHDをダウンロードするとその時点で暗号化が解除される
 Azure データセンターからの物理的な盗難などのケースに役立つ
• インターネットから RDP(3389)/ssh(22) ポートにアクセス可能な
状態にすることはリスクが高い。考えられる対策は以下。
1. Site-to-Site VPN/ExpressRoute 経由で、オンプレミスからしか
アクセスできないようにする。
2. NSG(Network Security Group)でアクセス可能なIPアドレスを指
定
3. 通常時は RDP(3389)/ssh(22) へのアクセスをブロックしておき、
必要な時だけ NSG の設定変更でアクセスを許可する。
 Azure Activity Log による NSG 設定変更時のアラート発行も設定
4. RD ゲートウェイを構築し証明書や多要素認証を組み合わせる。
クラウド環境
Operations Management Suite
オンプレミス DC
• セキュリティをはじめとするITインフラ品質強化
ログやシステム情報 マイクロソフトの知見および機械学習
• WindowsだけでなくLinux AzureだけでなくVMwareやAWS、物理サーバー
Log Analytics
改ざん不可能なクラウド
Service Map
ネットワークパフォーマンスモニター
OMS ワークスペースの作成
Azure 仮想マシンの OMS への接続
(New!) さらに進化した Log Analytics
新しい Log Analytics へのアップグレード
新しいクエリ言語に自動的にコンバート
旧環境のバックアップ
• ただし、Power BI連携だけは無効になり、別の方式で再設定が必要になるので注意。
脆弱性を指摘し、強化策を提示
侵入を検知
基本すべてのサーバーで有効にすること
• パブリッククラウドのセキュリティでもっとも注意すべきことは、
管理ポータルへの不正アクセス。
• Azure サブスクリプション管理者のアカウントに対しては、必ず
MFA (多要素認証) 設定しておくこと。
 IDとパスワードに加えて、SMS/電話/アプリなどでの認証を必須とする。
 組織アカウントでも Microsoft アカウントでも設定できる。
• Azure ポータルから Azure CLI 2.0を実行。
 認証済み状態で起動、アップデートの心配不要。
 PowerShell版も今後登場予定(現在プライベートプレビュー)
• 「いつの間にこんな機能が?」という発見があるかも。
Azure 仮想マシンにおける運用管理・高可用性設計のベストプラクティス
Azure 仮想マシンにおける運用管理・高可用性設計のベストプラクティス

Azure 仮想マシンにおける運用管理・高可用性設計のベストプラクティス