どこにも書いてない超ノウハウ！マイクロソフトが禁止しているWindows Server 2003からAzureへの移行「べからず集」

連載 :

プロジェクトリーダーや管理者なら知っておくべきWindows Server 2003からAzureへの移行

2015年4月22日(水)

はじめまして。NECマネジメントパートナーの吉田薫です。NECマネジメントパートナーで「System Center」を中心としたトレーニング講師を務めるかたわら、日経コンピュータをはじめとする、さまざまな雑誌および書籍に技術記事を寄稿しています。

さて、「Windows Server 2003からMicrosoft Azureへの移行」コラム、第2回は「どこにも書いてない、マイクロソフトが禁止しているWindows Server 2003からAzureへの移行のべからず集」をご紹介します。Microsoft Azureについては、充実したホワイトペーパーが数多く公開されています。それらを読み込むことで、Microsoft Azureへの移行に関しての概略は理解できると思います。

今回は、弊社が実施しているMicrosoft Azureトレーニングコースを受講することで理解できる、つまずきやすい点や、ホワイトペーパーには書かれていない、マイクロソフトが禁止している事項などをべからず集としてご紹介します。以下をざっと読んでいただくことで、基本的な考え方を理解できます。ホワイトペーパーと合わせてご一読いただけると良いと思います。

管理コンソールだけを使うべからず

「Microsoft Azureはクラウドサービスだから、Webブラウザの管理コンソールを使って管理するものだ」と思い込んでいませんか？

実はMicrosoft AzureはWebブラウザだけでなく、コマンドラインやPowerShellからも管理することができます。コマンドラインは、Windowsだけでなく、Mac OS XやLinux用のものも提供されていますので、お気に入りのコンピュータから管理できます。これらを活用すれば、バッチファイルやスクリプトを使った自動管理も可能です。さらに一部の操作については、PowerShellでなければできないものもあります。

リソースの監視を怠るべからず

仮想マシンを作成したり、仮想ネットワークを作成したりと、Microsoft Azureではさまざまなリソースを作成できます。ここで忘れてはならないことは、「Microsoft Azureにリソースがあれば、それは課金される」ということです。そのためリソースを監視し、不要となったリソースはすぐに削除してください。また仮想マシンについては、稼働中のみ課金される仕様のため、現在不要な仮想マシンはシャットダウンすることで、月々の使用料金を減らすことができます。

上限値であきらめるべからず

Microsoft Azureで仮想マシンやWebサイト、SQLデータベースなどを複数デプロイしていると、意外と早い段階で上限値に到達し、それ以上、デプロイができなくなるケースがあります。これは「クォータ」と呼ばれています。クォータは、マイクロソフトの「嫌がらせ」ではなく、何かのミスで必要以上にデプロイを行ったために使用料金が跳ね上がるのを防止するための安全装置です。そのため、マイクロソフトのサポートに連絡すれば、クォータの上限値は簡単に変更してもらえます。

セキュリティを無視するべからず

Microsoft Azureはインターネット経由でアクセスするクラウドサービスのため、管理者の設定次第でいとも簡単にぜい弱となります。例えば、仮想マシンを格納しているストレージのアクセスを既定の「プライベート」から「パブリック」に変更すると、誰でも仮想マシンのファイルをダウンロードすることが可能な状態となります。マイクロソフトの高度なセキュリティで保護されているMicrosoft Azureですが、その状態を保つためには、常に正しいセキュリティの知識と設定が必要です。

万能と過信するべからず

Microsoft Azureでは、仮想マシンにWindows Serverをインストールし、好きなワークロードを実行できます。ただし、オンプレミスのすべてのワークロードが実行できるわけではありません。例えば、Microsoft Azureの仮想マシンでは、オンプレミスのワークロードでよく使われているフェールオーバークラスターやネットワーク負荷分散は利用できません。どのワークロードに対応しているかを、事前に調べることが重要です。なお、万能ではないからといって悲観的になる必要もありません。必ず、代替案が用意されています。それを検討しましょう。

ここでは一つの例として、フェールオーバークラスターやネットワーク負荷分散のシステム代替手段をご紹介します。

フェールオーバークラスターの利用シナリオで一番多いのは、SQL Serverの可用性の向上でしょう。Microsoft AzureでSQL Serverの可用性の向上では、AlwaysOn可用性グループを検討してください。AlwaysOn可用性グループはSQL Server 2012で実装されたミラーリング機能で、共有ストレージを用意する必要がないため、Microsoft Azureの仮想マシンで使用できます。また、東日本と西日本のそれぞれのリージョンにSQL Serverをインストールした仮想マシンを作成して、リージョン間でAlwaysOn可用性グループを構成すれば、さらなる可用性向上が期待できます。

ネットワーク負荷分散の代替手段には、エンドポイント負荷分散があります。エンドポイント負荷分散は、Microsoft Azureの仮想マシンが標準で実装している機能で、インターネット経由のアクセスを複数の仮想マシンへ負荷分散します。インターネットを経由せずに負荷分散を行いたい場合は、内部ロードバランサーも用意されています。エンドポイント負荷分散と内部ロードバランサーは、追加費用なしで利用できるので活用したいものです。

さらに高度なネットワーク負荷分散の要求がある場合は、有償ですがTraffic Managerと呼ばれるMicrosoft Azureのサービスも用意されています。Traffic Managerであれば、Microsoft Azure以外のサービスを負荷分散のクラスタに登録したり、負荷分散のアルゴリズムを細かく設定したりすることが可能です。

標準の運用管理機能だけで満足するべからず

Microsoft Azureには標準でイベントやパフォーマンスの監視、さらにパフォーマンス情報と連動したアラート通知などの機能が用意されています。しかしこれらの機能は、あくまでもMicrosoft Azureのインフラストラクチャを監視するためのものです。ですから、仮想マシン内で稼働しているActive Directoryなどサービスの監視はできません。

仮想マシンの中まで監視するためには、Microsoft System Center 2012 R2（System Center）を併用します。System Centerは、もともと、社内システムの運用管理を行うための製品でしたが、現在はMicrosoft Azureにも対応しています。System Centerに含まれているOperations Managerは、仮想マシン内のActive Directoryを詳細に監視できます。

他にも、管理タスクを自動化するOrchestrator、バックアップによりデータを保護するData Protection Managerなども、Microsoft Azureに完全対応しています。