オンプレからAzureへの移行の際に忘れてはいけない2つのこと

2019.12.03

  • このエントリーをはてなブックマークに追加

オンプレからAzureへの移行の際に忘れてはいけない2つのこと | Azure相談センターブログ

オンプレミスのシステムが更改を迎える時、移行先に同じオンプレミスが選ばれることもありますが、運用面やコスト面の改善から移行先にクラウド環境が選ばれるケースが増えています。クラウド環境の中でもAzureは堅牢なグローバルデータセンターで構成されており、基幹系システムの移行先としても採用が増加傾向にあります。クラウドへ移行といえば、大別してPaaSやSaaSといったクラウドベンダーが提供するサービスを利用する「クラウドネイティブ」な方式と、IaaSといったクラウドベンダーが提供するインフラを利用する「クラウドリフト」が挙げられます。当社のパートナー様へヒアリングの平均では、クラウドリフトとクラウドネイティブが半々の50:50の結果が出ています。IaaSは展示会等ではあまり表に出てきませんが、SIの現場ではよく使われる環境なのです。

IaaSへのリフト案件は結構多い

IaaSへのリフト案件は結構多い

背景としては、既存のオンプレミスのシステムを「できるだけそのまま」Azureに移行したいという要件があり、特に重要な基幹系のシステムは、まずは一旦クラウドにそのまま「リフト」して、次のフェーズでクラウドに適した形への「シフト」を検討するという「リフト＆シフト」のスタイルで移行されるケースが多く見られます。このシフトの移行先にIaaSが選ばれているのです。

【関連記事】
・Microsoft Azureとは
・他製品と比較した際のAzureの特長は何ですか？

システムをSaaSやPaaSに移行するメリットは、移行先のサービスの構築や運用の負担を自前で構築や運用する場合と比べて大幅に低減できる点にあります。しかしその反面、使えるサービスの動作要件や運用ポリシーについては提供側の制約を受けることになります。反対にIaaSへの移行は、自前でサービスの構築や運用を行う負担はオンプレミスと変わりませんが、動作要件や運用ポリシーの自由度は高い特徴があります。 IaaSへ移行することで、SaaSやPaaSのようなサービス側の制約に縛られずに、現状のシステムに近い環境をAzure上に構築できます。この点はとても便利なのですが、IaaSへの移行は下記の2点にご留意下さい。

留意点1. IaaS環境は利用者の責任範囲が広い

SaaSやPaaSと比較して、IaaSは利用者の責任範囲が広いので、特にアプリケーションやミドルウェアの障害対策は利用者の責任で対策が必要です。IaaSのメリットは上述の通り構成の自由度にありますが、障害対策はオンプレミスと同様の対策が必要になります。 AzureやAWSといった大手のクラウド環境でも広域の障害が起きる可能性はゼロではなく、広域障害が起きてしまった時は、障害対策を十分に取っていなかった多くの企業がシステム停止に陥ることがありました。また、IaaS上で運用するソフトウェアについても障害を起こさないことが保証されているわけではないため、基幹系などの止められないシステムでは利用者の方で障害対策が必要です。 Azureの利用者の責任範囲は下図の通りですので、IaaSを利用する場合、障害への対策は必須といえます。

責任共有モデル図

責任共有モデル図

留意点2. クラウド環境では物理的な共有ストレージが使えない

Windows環境の冗長構成で一般的に使われているWSFC（Windows Server Failover Clustering *1）は、動作要件に共有ストレージを必要とします。しかしAzureを始めパブリッククラウド環境上では物理的な共有ストレージを使えません。このため何らかの対策が必要になります。

Azure環境へ移行した重要な基幹系システムを守るために、オンプレミス環境と同様の冗長構成をIaaS環境でも構築するのは、非常に有効な対策です。オンプレミスと同じようにAzure上でもWSFCを使うといった要件も多いでしょう。

しかしWSFCに必要な共有ストレージはどのように対策すれば良いのでしょうか？

答えは、サイオステクノロジー社のAzure向けの高可用性ソリューションです。当ソリューションでは、データレプリケーション製品のDKCE（DataKeeper for Windows Cluster Edition *2）を用いて論理的な共有ストレージをWSFCに提供し、オンプレミスと殆ど同じ手順で冗長構成をAzureのIaaS上に構築できる画期的なソリューションです。

*1：Windows Server OS標準のHAクラスター機能。複数台のサーバーを束ねてクラスタリングを実現し、稼働系に障害が発生しても待機系に自動的に切り替えることで、運用の継続を可能とします。
*2：DataKeeperは稼働系と待機系のローカルディスク同士をブロックレベルでリアルタイムに同期することにより、HAクラスターからはミラー領域を論理的な共有ストレージとして認識されます。DataKeeperはオンプレミス環境でも使えますが、Azureのようなクラウド環境上でも使えます。Azure環境では物理的な共有ストレージは使えませんが、DataKeeperを使うことでWSFCからは論理的な共有ストレージとしてミラー領域は認識されます。これにより、オンプレミスと殆ど同じ手順でWSFCによるHAクラスターをAzure上でも構築できるので、既知のWSFCのナレッジを最大限活かすことができます。

WSFCイメージ図

WSFCイメージ

WSFC管理画面

WSFC管理画面

DKCEは論理的な共有ストレージの機能のため、汎用的に使用できます。保護対象のソフトウェアの要件はWSFCに準じるので、オンプレミスのWSFCで保護できるソフトウェアであれば、Azure上で当構成を適用することができます。

例えば典型的な基幹系のSAP、JP1、HULFTやSQL Server、ファイルサーバーなどがよく対象になっています。これらの他にも、WSFCで保護可能なソフトウェアが当構成でAzureに移行されています。

いかがでしたでしょうか。詳細は、Azure 相談センターを運営するSB C&Sのパートナー・サイオステクノロジー社が提供する、下記ページもあわせてご参照ください。導入事例や詳細な構築手順書をご用意しています。

[Azure連携ソリューションページ]　 https://sios.jp/bcp/cloud-ha/azure/
[LifeKeeper,DataKeeperに関するお問い合わせはこちら]　 https://mk.sios.jp/BC_Web_Free-entry_Inquiry.html

著者紹介：サイオステクノロジー株式会社　BC事業企画部　クラウドサービスグループGM　西下 容史氏

※本記事は、サイオステクノロジー株式会社より寄稿いただいたものです。

PHOTO：StartupStockPhotosによるPixabayからの画像