Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

2017年8月に実施したウェビナーの資料です。

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

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

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

×