CT06

(1)

(2)

廣瀬一海（デプロイ王子） 日本マイクロソフト株式会社 Azure テクノロジースペシャリスト 愛称「デプロイ王子」/ 元 Microsoft MVP (Azure) でした。現在は、Microsoft Azureに関する様々な技術支援を行っています。お客様とAzureの使い方について設計や検証を一緒に行う活動の傍ら、コミュニティやセミナーの登壇、Webメディアへの記事執筆活動なども行っています。

(3)

(4)

(5)

可用性性能・拡張性運用・保守性移行性セキュリティシステム環境・エコロジー

(6)

(7)

何のため

どうやって

誰が運用

どのような

復旧目標

復旧時点

どこで

(8)

ビジネスオーナ/社内サービスチー

ム

(9)

可用性

(10)

IPA 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開

(11)

(12)

(13)

回復性

アーカイブ

_{災害復旧 (DR)}

_{高可用性 (HA)}

RPO/RTO

RTO >> 0 RTO > 0 RTO = 0

コスト/複雑さ Best For: データの削除データの破損コンプライアンス計画外障害の保護 HA のために再設計できない HA のコストの問題大規模障害ミッションクリティカルなアプリローカル障害 #decode17 #DI13

(14)

(15)

(16)

(17)

可用性 Error Budget (年間) Error Budget(月間) 99% 3.65 日 7.2 時間 99.9% 8.76 時間 43.2 分 99.95% 4.38 時間 21.6 分 99.99% 52.56 分 4.32 分 99.999% 5.26 分 25.9 秒 #decode17 #DO05

(18)

可用性 Error Budget

(年間) Error Budget(月間) 例

< 99% 3.65 日 7.2 時間バックアップ & 迅速・確実なリカバリ_{(Infrastructure as Code)} 99.9% 8.76 時間 43.2 分シングルリージョンHA 99.95% 4.38 時間 21.6 分 99.99% 52.56 分 4.32 分マルチリージョン (Act/Stb) 99.999% 5.26 分 25.9 秒マルチリージョン (Act/Act) #decode17 #DO05

(19)

Cache

フォールバック:

ローカルキャッシュからデータを返す

99.95% × 99.99% = 99.94%

2 リージョンの複合 SLA = (1 − (1 − N) (1 − N)) x Traffic Manager SLA (100% – (0.05% ×0.05%) x 99.99% = 99.9899%

https://docs.microsoft.com/azure/architecture/resiliency/

100% - (0.001% × 0.1%) = 99.99999% 99.95% × 99.99999% = 99.95%

(20)

(21)

(22)

(23)

SQL Server Always on / Apache Cassandra / Couchbase etc (XDCR) / MySQL Galera Cluster MySQL Master – Slave etc

(24)

(25)

• シリーズごとに1コアあたりの性能は異なる。

• ACU (Azure Computing Unit) をチェックする。

(26)

• 常に同時に３つのディスクへデータが書き込まれる。

• 最大で同時に２つのディスクが壊れても、データ損失なく稼働する。

VHD ファイル

(27)

• ジオ冗長ストレージ(GRS)を使うと、データが自動的に別データセ ンターにも非同期で複製される。 • 複製元での３重化＋複製先での３重化＝合計６重化。 > 500 miles 東日本 西日本 Blob ストレージ Blob ストレージ

(28)

• GRS はストレージをペアリージョンに非同期で複製する。 • GRS の複製時にはOS 内での整合性は考慮されない。 • 複数のディスクがある場合、各ディスクが異なるタイミングで複製 されうる。 ➢ 記憶域スペースや LVM を使っている場合、不整合が生じうる。 • GRS のフェールオーバーはマイクロソフトの判断により実行される。 ➢ 利用者任意のタイミングでのフェールオーバーはできない。

災害時の業務継続が目的であれば、別の手段も検討する。

(29)

• 所有しているリソースに影響を及ぼしうる Azure 上の問題について、

情報や解決策を提供する。

➢ 自分の所有しているリソースに影響のない問題は表示されない。

(30)

(31)

• Azure 仮想マシンでは原則としてディスク共有型のクラスタを構成 できない。 ➢ とくにファイルサーバーやDBサーバーにおいて要注意 • RDMBS の機能や3rd パーティのソリューションを利用した、ディスクを共有しない冗長化構成を考える。 〇 Azureではこちらを利用する × Azureでは原則として利用できない

(32)

• Windows Server 2016 の機能である S2D (Storage Space

Direct : 記憶域スペースダイレクト)を使い、Azure 仮想マシンで SQL Server AlwaysOn フェールオーバークラスターを構成できる。

• ただし S2D を使えばあらゆるワークロードでディスク共有型クラスタが構成できるわけではない。利用

(33)

• Azure 仮想マシンを複数台構成にするときは、可用性セットを定義する。 • これにより、１つのラックの障害で２台の仮想マシンが同時に停止することを回避できる。 • 可用性セット自体にクラスタリング・負荷分散・データ複製などの機能があるわけではないので注意すること。障害ドメイン障害ドメイン障害ドメインラック FC ・・・・・・ルータラック FC ・・・・・・ルータラック FC ・・・・・・ルータ可用性セット “AS1”

(34)

• 障害ドメイン (FD) ➢ 同時に物理障害が起こりうる単位 ≒ ラック • 更新ドメイン (UD) ➢ 同時にメンテナンスを行う単位

(35)

• 2017年2月にGAした仮想マシンの新しいディスク形式。 • いろいろなメリットがあるが、 ➢ ストレージアカウントの作成・管理が不要に ➢ スナップショット、仮想マシンイメージの容易な作成 ➢ Blobとしてのエンドポイントが無い • 実は Managed Disk では可用性も向上している！ ➢ 可用性セットに含まれる仮想マシンのManaged Diskは自動的に異なる障害ドメインに配置される。 ➢ 可用性セットを構成する場合は、Managed Disk を使 うことを強く推奨！

(36)

(37)

(38)

• 「理由はよくわからないけど何か調子が悪い」というときに実行し

(39)

(40)

• Azure 仮想マシンの

ディスクをまるごとバックアップ

• 稼働中に

オンライン

でバックアップ取得可能

• Windows にも Linux にも

対応

• Azure ポータルの仮想マシン設定画面から、

(41)

• 主要なAzure Backupの利用形態として以下の３種類がある。

1. Azure 仮想マシンのバックアップ

2. オンプレミスの仮想マシンやDBのバックアップ

3. ファイルやフォルダのバックアップ

今日お話しするのはこれ Azure Backup

(42)

(43)

• Windows では VSS を利用したアプリケーション整合性バックアッ プが取得できる。 ➢ SQL Server などの VSS に対応したアプリケーションであれば、アプリケーションのレベルで静止点を取って、バックアップを行う。 • Linux でもユーザーが独自にバックアップ事前・事後スクリプトを 設定することにより、アプリケーション整合性バックアップを取得することができる。(プレビュー) ➢ VM 内にスクリプトを配置しておくと、バックアップ事前・事後にそれが自動的に実行される。 ➢ スクリプトが無い、もしくは失敗した場合でも、ファイルシステム整合性バックアップが実行される。

(44)

1. 仮想マシン全体のリストア

➢ Managed Disk の仮想マシンであれば、そのままManaged Diskの仮想マ

シンとしてリストアされる。 2. ディスクのストレージアカウントへの復元 ➢ 復元したディスクの利用方法にもいくつかのパターンがある 1. ARMテンプレートを使って復元したディスクから新規仮想マシンを作成 2. 復元したディスクを既存の仮想マシンに接続 3. PowerShellを使って復元したディスクから新規仮想マシンを作成

(45)

• Azure Backup は現時点で以下をサポートしない。  1TB よりも大きなディスク ➢ つまり 4TBディスクは未サポート  16本よりも多くのディスクを接続した仮想マシン  存在している仮想マシンの上書きリストア ➢ まず仮想マシンを削除してからリストアする必要がある • いずれも将来的にはサポートされる予定。

(46)

• 仮想マシン全体ではなく、特定のファイルやフォルダだけをリスト アする機能もある。(プレビュー機能) • 過去時点のディスクがiSCSI ディスクとして仮想マシンに接続され、そこから必要なファイル・フォルダを取り出すことができる。 Azure Backup iSCSI ディスクとして接続

(47)

(48)

(49)

• Azure Backup では稼働中のオンラインバックアップが可能だが、 バックアップ取得は業務ピーク時を外すこと。 ➢ バックアップ取得時にはストレージアカウントに対して大量のアクセスが発生し、業務に影響を及ぼす可能性がある。 • 多数の仮想マシン/ディスクを1つのストレージアカウントに詰め込 みすぎないようにする。 • 特にバックアップ・リストアの性能が重要な仮想マシンについては、 Premium Storage の利用を検討する。

(50)

• ジオ冗長ストレージ(GRS)により、バックアップデータを別リー

ジョンに複製することもできる。

Azure Backup

(51)

• GRS 同様、 Azure Backup サービス自体のフェールオーバーもマ

イクロソフトの判断で実施される。

(52)

(53)

• Azure 仮想マシンのデータを、常に別のAzure データセンターに 同期する。 • 大規模災害で Azure データセンターが被災したときに、複製されたデータをもとに別の Azure データセンターで仮想マシンを起動 し、業務を再開できる。 • 料金は¥2,550＋ストレージ料金のみ。 DR 用仮想マシンの料金が発生するのは、フェールオーバー先で仮想マシンを起動したときのみ。

(54)

• Azure Site Recovery には以下の２種類がある。

1. オンプレミスから Azure への DR

2. ２つの Azure データセンター間での DR (プレビュー)

(55)

(56)

(57)

(58)

• VM内で動作するエージェントが、同一リージョンのキャッシュスト

レージに変更データを書き込む。

(59)

(60)

(61)

• フェールオバー後に仮想マシンが正しく起動するか、事前にテストしておくことが重要。 • 複製元仮想マシンを稼働させたまま、テストを実行できる。

(62)

• 一般的にフェールオーバー手順は複雑になりがち。 ➢ 手順書を見ながら実行しても、ミスする可能性がある。 • 複数の仮想マシンからなる複雑なシステムのフェールオーバー処理を、復旧計画として定義できる。 ➢ 仮想マシン起動の順序や、Azure Automation Runbook の実行などを定義しておく。 ➢ フェールオーバーの際は、この復旧計画を実行すればよい。

(63)

• ASR はディスクイメージ全体を非同期で複製する。

➢ Active Directoryドメインコントローラーでは、データの不整合が発生する

可能性がある。

• 原則として、Active Directoryドメインコントローラーには ASR を利用しない。

Active Directory によるデータ複製

(64)

• 1TB を超えるディスクはサポートされない。 ➢ これは Azure リージョン間での ASRについての制約。オンプレミスから Azure への ASR では、4TB ディスクがサポートされた。 • Managed Disk はサポートされない。 • 以下の構成については、フェールオーバー時に復旧計画から自動化スクリプトを実行して構成する必要がある。 ➢ ロードバランサー(内部・外部ともに) / Traffic Manager

(65)

• ASR ではフェールオーバー時にIP アドレス体系を保持することも変更することも、どちらも可能。 ➢ IPアドレス体系を保持する場合、オンプレミスを含めたルーティングやIPアドレスのバッティングの回避などについての考慮が必要。 ➢ IPアドレス体系を変更する場合、アプリの正常動作について確認が必要。 10.3.0.0/16 10.2.0.0/16 IPアドレス体系重複のため同時接続はNG IPアドレスが変わっても正常に動作するか？ IPアドレス体系を保持しない IPアドレス体系を保持する

(66)

• 社内 WAN からAzure 東日本リージョンへ ExpressRoute で接続していた。 • 災害が発生、ASR で西日本リージョンへフェールオーバーした。 • 社内 WAN から西日本リージョンへどう接続する？ 1. あらかじめ西日本リージョンへも ExpressRoute を引いておく。 ➢ 災害対策用であれば従量課金がおすすめ。 2. Site-to-Site VPN 接続する。 ➢ 例えば、関西の業務拠点にVPN装置を配置しておき、フェールオーバー時に接続する。 3. 例外的にインターネット経由での接続を許可する。 ➢ 大規模災害時には社外からのアクセスに対するニーズが高まると予想される。

(67)

Office in Los Angeles 10.1.0.0/16

AS 64496

Office in New York 10.2.0.0/16

AS 64496

Network carrier s IP VPN or Customers backbone network

Virtual Network Virtual Network Ex pr es sR ou te Ex pr es sR ou te ExpressRoute Los Angeles ExpressRoute New York West US 10.100.0.0/24 East US 10.200.0.0/24 Microsoft s backbone network Gateway Gateway 広域専用線網 

(68)

https://docs.microsoft.com/azure/ architecture/reference-architectures/ virtual-machines-windows/

(69)

https://docs.microsoft.com/azure/ architecture/reference-architectures/ virtual-machines-linux/

(70)

(71)

機能 ERT (推定

復旧時間) RPO (目標復旧時点)

地理レプリケーションバック

アップからの地理リストア <12時間 <1時間アクティブ地理レプリケーション <30秒 <5秒

(72)

(73)

(74)

(75)

パターン _{ERT (推定} 復旧時間) RPO (目標復旧時点) アクティブ/パッシブデプロイと DB 併置によるDR 障害検出時間 + DNS TLL <5秒アクティブ/アクティブデプロイによるアプリ負荷分散障害検出時間 + _{DNS TLL} <5秒アクティブ/パッシブデプロイによるデータ保存 (読み取り専用) 0 <5秒アクティブ/パッシブデプロイによるデータ保存 (読み書き) 障害検出時間 + データ消失の猶予期間 0 https://docs.microsoft.com/azure/sql-database/sql-database-designing-cloud-solutions-for-disaster-recovery

(76)

App Service Cosmos DB DatabaseSQL Redis Cache Storage (Contents) Storage (Log, Config, etc)

CDN App Service Cosmos DB DatabaseSQL Redis Cache Storage (Contents) Storage (Log, Config, etc) Traffic

Manager

Active Region Standby Region

(77)

Traffic Manager マニュアル切り替え可能 (優先度変更) SQL Database マニュアル切り替え可能 (Failover Group内でスイッチ) Storage マニュアル切り替え不可 Cosmos DBマニュアル切り替え可能 (Write Region変更) Azure Storageで同期するのは、対抗リージョンでの即時回復、書き込みが不要な静的データ(ログや構成ファイル、バックアップデータなど)に限定する。即時読み取りが必要な場合は、RA-GRSでセカンダリを読めるようにしておく。

(78)

App Service Cosmos DB DatabaseSQL Redis Cache Storage (Contents) Storage (Log, Config, etc)

App Service Cosmos DB DatabaseSQL Redis Cache Storage (Contents) Storage (Log, Config, etc) Traffic

Manager

Active Region Standby Region

(79)

(80)

API Apps Search Cosmos DB (Document) Blob Storage 利用者旧 IMAGE WORKSシステム(Java/Struts/PostgreSQL) 認証 App Service Microsoft Azure Storage Queue Blob Storage Function s Storag e

Queue _{SQL Database} Cosmos

DB Cognitive

Services _LearningMachine Function s PC Clients(Windows/Mac) Mobile Clients(iOS/Android) API Gateway 外部システム Application Insights Azure Monitor 国内データセンター Web Apps Token .NET • マスターファイル保管 • アカウント管理 • 権限管理 Identity Framework Function s REST/OAut h2 SPA (Browser App) SPA (Browser App) 負荷モニター/オートスケール

(81)

Microsoft Azure Search Cosmos DB Blob Storage Cosmos DB SQL Database Search ローカルでのインデクシング Cosmos DB Search ローカルでのインデクシングリアルタイムGeoレプリケーション

App Service _{App Service} App Service Traffic Manager 西日本(Primary) 米国東部西ヨーロッパ日本ユーザ米国ユーザヨーロッパユーザオンプレミス IMAGE WORKS ローカルでのインデクシング

Azure CDN _{Azure CDN} _{Azure CDN}

SQL Database リアルタイムGeoレプリケーション SQL Database Blob Storage Blob Storage

(82)

(83)

✓

負荷に適応するリソース

- Adaptive Scale

✓

稼働率

100%

- Zero Downtime

(84)

(85)

(86)

Server HW Hypervisor VM App Container App Deploy Ready-to-go-Infrastructure Provision/Boot Install/Configure

VNet/Virtual Private Cloud

いつでもセルフプロビジョニング

できるリソースプール

(87)

pre-provisioned ready to host

pool of ready-to-go

https://msdn.microsoft.com/en-us/magazine/mt793270

Server HW Hypervisor VM App Container App Deploy Pre -provis ioned / read y to ho st どのノードもいつでもデプロイできるように ”暖めてある”リソースプール

(88)

そのサーバーレスネイティブな内部実装 ILB Instances Kudu LoadBalancer Deployer _Telemetry Prod/Stage Blob Allocate Deploy Allocate

(89)

(90)

90

(91)

自分の目と手で試しましょう！

91 ビデオで過去のウェブセミナーを視聴する ▶▶▶ http://aka.ms/dx-ondemand セミナー・ウェブセミナーに参加する ▶▶▶ https://aka.ms/azjp-events Azure の活用を電話で相談する ▶▶▶ 0120-952-593 またはお問い合わせフォーム https://aka.ms/adj 対面で Azure の活用を相談する Azure 相談窓口 ▶▶▶ Azure Antenna （渋谷）月～金午前中および特設イベントがない月曜日午後相談窓口 (名古屋）