2016年10月24日月曜日

Hyper-V仮想マシンからAzureへのフェールオーバーとフェールバック

Microsoft Azureは、オンプレミスのサーバーをAzureに複製(レプリケーション)し、必要に応じてフェールオーバー(障害時の切り替え)ができます。ただしHyper-VホストはWindows Server 2012 R2が必要です。

Windows Server 2012 R2のHyper-Vホストは以下の仮想マシンをサポートします。

  • 第1世代(BIOS)および第2世代(UEFI)の仮想マシン
  • VHD形式およびVHDX形式の仮想ディスク

一方、Microsoft Azureがサポートする仮想マシンは以下の通りです。

  • 第1世代(BIOS)
  • VHD形式の仮想ディスク

そのため、Hyper-Vの第2世代は第1世代に変換され、VHDX形式はVHD形式に変換されます。この処理は自動的に行われるため、特に作業は必要ありません。

一方、フェールバック(Azureで起動した仮想マシンをオンプレミスに戻す)時は注意が必要です。

大規模災害などで、データセンタが破損したあと、システムが復旧したとします。この場合、Azureから「フェールバック」を行うことで、元のシステムを復元できます(操作メニューは「フェールオーバー」を使います)。

オンプレミスの仮想マシン存在しなくても「オンプレミスにVMを作成する」オプションを指定すれば、自動的に復元します。

計画フェールオーバー2

この時、Azureから戻ってきた仮想ディスクはVHD形式に変換されたままですが、容量可変ディスクに戻ります。以前の状態を覚えているのでしょうね。

ただし、フェールバック(Azureから戻す)で、Azureの(変換された)第1世代PCを(元の)第2世代に戻すことはできません。しかし、どうもAzureは第2世代に戻そうとするようです。こちらも以前の状態を覚えているようですね。

もちろんこの作業は失敗するため、第2世代の仮想マシンを戻す(フェールバックする)ことはできません)。図のエラーはそれを示しています。

本記事の内容は「Microsoft Azureによる災害復旧手法 ~Azure バックアップとAzure Site Recoveryでの仮想マシン保護~」で扱っています。

2016年8月23日火曜日

NFC0202G

特徴的なクラウド事例やインタビュー記事を集めてきました。

【クラウドの基礎】


【クラウド利用事例】その1


【クラウド利用事例】その2


【クラウド利用事例】その他

  その他にもこんなものがあります。


【開発と運用のアーキテクチャ】

DevOpsなど、開発と運用についてのインタビュー記事です。

【その他資料】

Amazon Web Services編

 

Microsoft Azure編

2016年8月16日火曜日

Microsoft Azureの演習中に起きたトラブル

最後の演習中、Microsoft Azureの管理ポータル(クラシックポータル)が不具合を起こしました。終了時刻が近付いていたので不本意ながら中断して、口頭での解説だけを行いました。

あとで見たら、エラー報告が上がってました。

最後の、一番大事な演習だったので残念でした。受講者の皆様には、サポートサービス「グローバルスクエア」の質問回数制限を緩和させていただきます。

ご迷惑をおかけしました。

通知ログ

2016年6月5日日曜日

Azure仮想マシンのMACアドレス

先の記事「Azure仮想マシンの一時ディスク: サイトリカバリの場合」もあわせてお読みください。

Microsoft Azureの仮想マシンは、必ずDHCPクライアントとして構成します。ただし、IPアドレスが変化するのは何かと不便なので、多くの場合は静的なIPアドレスを割り当てます。

これは、DHCPの「予約」に近いもので、PowerShellまたは新管理ポータルを操作することで構成できます。

DHCPクライアントとして構成するのは、物理マシンを移動するとき、仮想マシンが再作成され、NICが新規に割り当てられるためとされています。

そうすると、当然MACアドレスも変化することになりますね。

マイクロソフトのドキュメント「Virtual Network FAQ」にも、はっきりと書かれています(2016年3月15日付)。

  • VMに静的なMACアドレスを構成できますか。
  • いいえ。MACアドレスを静的に構成することはできません。

ただし、以下の記述もありました。

  • MACアドレスは、一度作成されると、VMで同じものとして残りますか。
  • いいえ、ただし変化するのは停止済み(割り当て解除済み)状態になった場合だけです。ユーザーがVMのサイズを変更したり再起動した場合、またはサービス復旧やホスト サーバーの計画的なメンテナンスの場合は、MACアドレスは維持されます。

すみません。ホストの計画的なメンテナンスでも変化するものだと思っていましたが、これは変わらないそうです。

Hyper-Vの仮想マシン構成ファイルにはMACアドレスを記述できるので、それを使っているのでしょうか。

なお、静的なMACアドレスを使う計画はあるようです。Azureの要望リストに「Static MAC address」というのがあり、こんな回答が出ていました(2016年5月3日付)。

The deployment of static MAC address has been started. You will see that MAC addresses for VMs will be static through resize and maintenance operations currently. The work to maintain a static MAC address through a stop (deallocated) and restart operation is rolling out currently.

静的MACアドレスの展開のサポートをはじめます。現在でも、仮想マシンのMACアドレスはサイズ変更やメンテナンスがあっても変更されません。しかし、仮想マシンを「停止(割り当て解除)」してから再起動すると変化します。

DSC00409S
写真は本文とは関係ありません

2016年6月4日土曜日

Azure仮想マシンの一時ディスク: サイトリカバリの場合

Microsoft Azureには「Site Recovery」という機能があり、オンプレミスの仮想マシンまたは物理マシンをAzure上に複製できます。もちろん、システムディスクだけではなく、データディスクも複製できます。

ただし、Azureの仮想マシンにはいくつかの制約があり、完全に同じ構成にはなりません。Azure上の仮想マシンはMicrosoft Azureの制約を受けるためです。

まず、サイズはAzureで決められたものになります。既定では、オリジナルの仮想マシンに最も近いものが選ばれるようですが、選択できる範囲で変更もできます。なお、接続可能なデータディスクの台数はサイズに依存するので注意してください。

次に、Azureの仮想マシンには揮発性の一時ディスクが追加されます。Azureの仮想ディスクが配置されるBLOBはあまり高速ではないため、ページファイルを高速な一時ディスクに配置することで全体の速度を稼ぎます。

一時ディスクは、仮想マシンを配置した物理マシンに接続されており、仮想マシンが別の物理マシンに配置された場合は新しく作り直されてしまいます(図)。

この時、ネットワークカードも新たに作成されます。Azureの仮想マシンがDHCPクライアントなのはこれが理由です。

Azure-4
図「ひと目でわかるAzure 基本から学ぶサーバー&ネットワーク構築」より

通常、一時ディスクはDドライブが割り当てられますが、「利用可能なディスクの内、最後のドライブ文字」を使うのが基本です。ドライブ文字の変更は、Azureチームのブログ記事「Windows 仮想マシンのデータ ドライブとしての D ドライブの使用」等を参照してください。

Site Recoveryを使う場合で、オリジナルの仮想マシンに複数のドライブが接続されている場合は、以下のようになります。

  • システムディスクを管理者が指定
  • 一時ディスクは最後のドライブ文字を使って追加

Site Recoveryをを構成すると、管理ポータルでは「どのVHDファイルがシステムディスクを指定しろ」と言ってきました。表示されるのはVHDのファイル名です(システムパーティションとブートパーティションが異なるドライブだった場合、どちらを指定するででしょうね? システムパーティションでしょうか)。

Azure上の仮想マシンにある一時ディスクは、データディスクの次のドライブ文字を使っていました。たとえばCがシステムディスク、Dがデータディスクの場合、Eが一時ディスクになります。

さて、この一時ディスク「ページファイル以外の使い途がありますか?」とよく聞かれます。さあ、なんでしょうね。

主記憶が小さく、仮想記憶もなかった時代は、ファイルの中身をソートするために一時ファイルを作ることがありました。また、MS-DOSのパイプは、コマンドの実行結果を環境変数TEMPの示すフォルダーにいったん保存していました。たとえば、以下のコマンド

DIR |  SORT /+30

DIR > %TEMP%\1234567.tmp

SORT /+30 < %TEMP%\1234567.tmp

と同じ意味でした。

一時ディスクは、このような計算の途中結果を保存するのに適していますが、今はあまり使うことはないと思います。

2016年4月8日金曜日

Microsoft MVP受賞しました(Enterprise Mobility)

おかげさまで、今年もMicrosoft MVPを受賞しました。Enterprise Mobilityという分野です。Enterprise Mobilityには以下の分野が含まれます。

  • System Center Configuration Manager & Microsoft InTune
  • Identity and Access
  • Information Protection
  • Remote Desktop Services & Azure RemoteApp

私は2012年のみVirtual Machines(要するにHyper-V)で、他はDirectory Services(要するにActive Directory)だったんですが、昨年からいくつかの分野が統合・整理されています。

もともとMicrosoft MVPは、米国CompuServe(パソコン通信)のフォーラムで、マイクロソフトの技術情報を積極的に提供している人に対して感謝の意を表明したいというところからスタートしたそうです。

ちなみに私は、日本のパソコン通信Nifty Serveのマイクロソフト系フォーラムで積極的に書いていたところ、フォーラム管理者から連絡があり、アクセス料金が免除されていました。通称「フリーフラグ」というやつです。

日本のMVPは、パソコン通信ではなく、コミュニティ活動の評価からスタートしたため、初期メンバーはユーザー会の幹事が多かったようです。この時にMVPになっていれば、ビル・ゲイツを交えた少人数のミーティングにも参加できたのに残念です。

Microsoft MVPの選出基準は、専門分野ごとに多少の違いがあります。Microsoft MVPは個人に与えられるアワードなので「仕事として行っている場合は評価対象としない」という話も聞きました。でも、開発ツールならともかく、ディレクトリサービスやCRMを個人で使う人なんて、まずいません。不特定多数を対象にしている場合は評価対象になるのではないかと思います。

共通の評価基準は「どれだけ多くの人に情報を届けたか」です。明確な基準はありませんが、公募型のトレーニングを担当している場合は評価項目に含めることができるようです。

Microsoft MVPを取得すると、盾と賞状、それにピンバッジとネームカードがもらえます。盾は毎年新調されていたんですが「邪魔になる」という声があったのか、経費削減の姓なのか数年前から切り欠きの入ったリングを重ねていく形になっています。

このリングの加工精度が悪く、積み上げてもがたがたです。もうちょっと何とかならないものでしょうか。

さて、今回「Enterprise Mobility」ということで、Active Directory回りが評価されたようです。実はAzure ADなど、最新情報にはあまり詳しくありませんが、「この機会に勉強しない際」ということだと思うので、これから勉強して、みなさまに分かりやすい情報をお届けしたいと思います。

2016年3月11日金曜日

Microsoft Azureの仮想マシンへの接続遅延

Microsoft Azureの研修を実施中、仮想マシンへの接続遅延について質問されました。

パブリッククラウドの場合、接続遅延はインターネットサービス(ISP)の影響が大きいため、一般的な値を示すことはできません。

とは言え、実際に使っての値を知りたい気持ちは分かります。そこで、実測してみました。

接続環境は、教育コース「Microsoft Azureによるサイト間ネットワークの構築」をそのまま使いました。これは、Hyper-V上のWindows Server 2012 R2仮想マシンのRRAS(Routing and Remote Access)を使ってVPNサーバーを構成したものです。

接続先は西日本のデータセンターで、接続元はグローバルナレッジの東京教育センターです。

ping

確か、以前試したときは30ミリ秒くらいあったように思うのですが、ご覧の通り13ミリ秒程度です。

ところが、東日本のデータセンターと比較するの忘れてしまったので、もう一度仮想マシンを作りました。

残念ながら、ネットワーク設定もすべて削除したあとだったので、VPN接続も消えています。改めて作るのも面倒なので別の方法を使うことにします。

仮想マシンの構築は簡単にできます(クラウドのいいところです)。しかし、pingで使っているICMPを通すのは結構面倒です。そこで、SysInternalsのツール「PsPing」を使いました。これは任意のTCPまたはUDPポート番号を指定して接続テストを行うツールです。

結果

▼西日本
ping-osaka
VPNサーバーを経由していないせいでしょうか10ミリ秒程度になりました。3ミリ秒ほど高速になっています。

▼東日本
ping-tokyo
なんと3ミリ秒程度です。

こんなに早いとは思いませんでした。また、西日本とこれほど差があるとも思いませんでした。

「西日本と東日本は、そんなに差がないし、仮想マシンが少し安い西日本がいいですよ」と聞いていたんですが、これだけ遅延が小さいと考えますね。

ついでに、あまり迷惑にならない範囲でめぼしいサーバーにアクセスして見たところ、軒並み高速になっており、見たことのない小さな数字が並びました。

どうも、会社で契約しているインターネット接続回線の品質が上がっていたようです。インターネット接続回線の速度測定は、本当に当てになりません。

 

【追記】自宅から試しました

自宅から試したら、以下のような結果になりました。

  • 西日本…16ミリ秒程度(ただしパケットサイズが小さいときは一時的に25ミリ秒ほどになりました)
  • 東日本…8ミリ秒程度

ブロードバンドルーターのオーバヘッドが5ミリ秒くらいあるのでしょうか。