2012-03-01 7 views
0

当社はクラウドへの移行を考えています。私たちは現在のすべての要件(下記)を満たすことができますか?私たちは、高コストなしに将来的に容易に拡張できるようにしたいと考えています。asp.netアプリケーションをクラウドに移動することはできますか?

  • 5 ASP.net(下記参照、SQLデータベースを使用して)実行している4.0のウェブサイト
  • SQL Server 2008のExpressの(この上の8つのデータベース)を実行している
  • 2スケジューラサービスは、(電子メールなどの新規受注を経由して、毎晩レポートを送信
  • )デシベルでのMongoDBとMemcachedのは、サーバ

にインストールされている現在のウェブサイトは、セキュリティ上の理由から、データベース・サーバーから別のサーバー上にあります。

プロバイダとしてはWindows AzureAmazon Web Services (AWS)を考えていましたが、これは当社の要件に最も適していますか?

考慮すべき他の要因はありますか?

+1

価格を支払うことができるのであれば、すべてAmazon EC2インスタンスに確実に移行できます。小さくて安いものから始めるのもかなり簡単でしょう。 EC2インスタンスは、クラウド内の完全にリモートコントロール可能なVMです。非常にクールなもの。 –

+1

Azureよりも.netですべてのことをやっているのであれば、おそらくあなたの開発者にとってもっと自然な感じがするので、もっと良い選択になるでしょう。私はIISからAzureに移行しています。これは非常にクールです。Azureのユニークな機能(AppFabric for Cachingなど)を利用したくない場合は、変更することはほとんどありません。 – frenchie

+0

私は簡単に紺碧を使用してWindowsサービスを実行できますか? –

答えて

2

Re:SQLデータベース:(Windows Azureの場合)これはSQL Azureにマップされます。コストは最大100 MBのインスタンスで月5ドルから始まり、最大150 GBに達し、フェデレーションを超えています。

Re:5 ASP.net 4.0 Webサイト実行中:これらは自然にWindows Azure Web Rolesにマップされます。 「小さな」インスタンスは$ 0.12 /時間/インスタンスで、通常は2つのインスタンスが必要です(いくつかのシナリオでは単一障害点を避けるため)。負荷に応じて、5つのサイトをすべて同じインスタンスに配置することができます。あなたが非常に低い使用サイトを持っている場合は、$ 0.05 /時間/インスタンスの "超小型"インスタンスを検討してください。

Re:現在、ウェブサイトはセキュリティ上の理由から、データベースサーバーとは別のサーバーにあります。もちろんこれも実行可能です。

Re:2スケジューラサービス実行中:実行中のWindowsサービスは問題ありません。

Re:メールで夜間のレポートを送信します。新しい注文のdb: Windows Azureに直接焼くことはできませんが、問題はありませんが、これを行う簡単な方法がたくさんあります(SendGridなどの無料の場合でも)。

Re:高額な費用をかけずに容易に拡張できるようにしたい:あなたは実際のコストに関して数学を行う必要がありますが、Windows Azureは確かに拡大縮小できます。

Re:MongoDBとMemcacheもサーバにインストールされています:これらは両方ともAzureで実行できます。 MongoDBの場合はhttps://github.com/mongodb/mongoをチェックしてください。また、Azure Cachingサービスも利用できます(あなたのために管理されています)。

日時:いくつかの注目すべき違いが、これらは、機能(性能とコストの)非常によく似てい:私たちは最高の我々の要求に合うプロバイダなどのAzureやAmazon、について考えていました。

  1. Windows Azureは、サービスとしてのプラットフォームであり、仮想マシンを心配する必要はなく、アプリケーションであることを意味します。つまり、(基本的に)Zip形式のアプリケーションパッケージをクラウドにアップロードして実行します。 Amazonでは、仮想マシンを自分で扱うことになります。 Azureでは、管理されているWindows Server 2008のコピーを手に入れますが、必要に応じて管理作業を行うこともできます。あなたのアプリが本当にきれいではない古いインストールであれば(ただし、とにかく高価値のクラウド候補ではないかもしれませんが)、これははるかに有利です。
  2. Windows Azureには、ビジュアルスタジオからストレージシステムとVM、およびより一般的な機能を操作するのに最適なF5のエミュレータがあります。

Re:考慮する必要があるその他の要素はありますか。はい。どんなクラウドアプリケーションでも、スケーリングアウト(上向きではない)、一時的な再試行(クラウドサービス - クラウドサービスへの操作を再試行する必要があるかもしれません)に対処する必要があります。この利点は、スケーラビリティと信頼性がはるかに優れており(コスト効率が高い)、ノード間で実行する場合は単一障害点がありません。 VM上のストレージが永続的か一時的かを理解してください。より多くの考慮事項がありますが、これは主要なものです。

Windows Azure Pricing calculatorをチェックしてください。

幸運を祈る!そして、雲にようこそ。

0

熟練しているわけではありませんが、Asp.netはマイクロソフト製品であるため、私はAWSが難しいはずはないと聞いていますが、紺碧に移行しやすいはずです。考慮すべきもう一つのことはコストです。前回私がAWSにチェックしたのは、すでにMSDN購読料を支払っていない限り、大幅にコストがかかりませんでした。

1

スケーリングの質問と2台の物理サーバーを除いて、この機能をホスト環境に移行することができ、技術的には「クラウド」になります。これは、専用サーバーまたはVPS(仮想プライベートサーバー)、またはあなたが小さい場合でも共有サーバーになる可能性があります。

これらは時間の経過とともに成長を可能にすることができます...あなたはプロバイダとの間でアップグレードするだけで済みます。

ホスティングプロバイダーとのコロサーバーを使用することもできます。これは基本的に、ホスティングプロバイダーラックにハードウェアを置き、電力と帯域幅を使用することを意味します。彼らは帯域幅の使用量に基づいて課金します。

SQL Expressを使用しているので、各データベースは8GBに制限されています。そうすれば、あなたの成長はある時点で制限されます。それは、何かを再エンジニアリングしたくない場合、Expressから通常のSQLへのアップグレードを必要とします。

0

Windows Azureでの展開に必要なすべての要件は、問題ありません。あなたはこれを行う方法についてインターネット上の多くの情報を見つけることができます。

サービスをWindows Azureに展開する場合は、アプリケーションのコードレビューを実行して、Webアプリケーションでセッション状態や出力キャッシュなどを修正する必要があります。

これらをスケールアウトし、スティッキーではないラウンドロビンロードバランサの背後に座っているので、セッションステートがマシンに保存されていると、セッションステートで問題が発生します。たとえば、セッション状態をSQL AzureまたはWindows Azureテーブルストレージに分割する必要があります。Azureの中MongoBとMemcacheのインストール

は問題ではありません、あなたはそれを行う方法についての多くの情報を見つけることができますが、それは自分の役割とスクリプト

1

を設定するには、いくつかを必要とするだろう、あなたは考えがありますAppHarbourMemcachedMongoDBSQL Serverso onがあり、Azureよりも速く展開できます。私はのように Azureですが、かなりの学習曲線があり、SQL Azureとの接続がかなり悪いことがわかりました。つまり、DALの再エンジニアリングで、SQL Transient Failure Library =既存のプロジェクトのためのfaffを使用しています。

AppHarbourにはブロブストレージがありません。ファイルをアップロードする場合は、Azure Blob StorageやAmazon S3などを使用する必要があります。

これが役に立ちます。

0

codingoutloudは非常に詳細な回答を与えています。どのアプリケーションをAzure(または実際には他の多くのクラウドプロバイダー)に移行するかについて考えるには、2つの非常に重要な考慮事項を追加します。通常のAzureで

ローカル状態
、彼らはそれを移動またはアップグレードするために、いつでも役割のいずれかのインスタンスを停止する権利を留保します。つまり、どのロールでも少なくとも2つのインスタンスが常に必要であり、それらは透過的に負荷分散されます。あなたの現在のウェブサイトが現在個々のサーバー上で動作している場合、セッション状態やローカルディレクトリなどのファイルに依存している可能性があります。セッション状態をSQLに入れたり、一時データ用のCookieプロバイダを使用したり、ファイルをドライブするなど)、実際にAzureの多くの利点をバイパスし、「仮想サーバー」という概念を使用すると、規模の利益などを得ることができません。 しかし、地元の州に大きく依存しているサイトは、クラウドに移動する。

時間帯
すべてのAzureサーバーは、UTC時間で実行されます。単一のタイムゾーンからユーザーにサービスを提供する専用サーバー上で実行することに慣れている場合、実際にはユーザーが望んでいないDateTime.Now()などのものを使用する可能性があります。

Azureの上記のような制限はありません。最初からグローバルでスケーラブルなソリューションを構築することは非常に便利です。しかし、既存のアプリケーションを移植する際には、回避策があるにもかかわらず、上記のことが非常に難しいかもしれません。

他のところで述べたように、Azureには学習曲線があり、何らかの理由でドキュメントが豊富です。何らかの理由で助けにはならないようです。しかし、あなたが「得る」とすれば、Azureは本当に素晴らしいと思います。キューインフラストラクチャ、ブロブストレージ、テーブルストレージなど、スケーラブルなソリューションを構築するのに役立つ微妙な機能が多数あります。いくつかの点で、学習はあまりにも多くの選択肢を持つことによって妨げられています。

幸運を祈る!

関連する問題