8

Amazon EC2 または Microsoft Azure を使用して新しいプロジェクトをホストすることを検討しており、Amazon EBSまたはMicrosoft Azure ドライブを使用して、ASP.NET Web サイトの実行に使用されるファイルを保存することを計画しています。私の知る限り、これら 2 つのテクノロジは非常に似ており、どちらもクラウド ストレージ ( Amazon S3またはAzure Blobs ) によってサポートされる仮想ハード ドライブを提供します。EC2 と EBSが最近停止したため( Post Mortemを参照)、EBS と Azure ドライブの比較について詳しく知りたいです。具体的には：

  1. Azure ドライブは、単一のインスタンスで読み取り/書き込みとして、または複数のインスタンスで読み取り専用としてマウントできることを知っています。同じことが EBS にも当てはまりますか? また、SMB プロトコルを使用して、複数のインスタンスで Microsoft Azure ドライブを読み取り/書き込みモードで使用できるとも聞きました。誰でもこれを経験したことがありますか？

  2. 今日のサービス停止前から、Amazon EBS の信頼性について多くの人が不満を漏らしていました。複数の EBS ボリュームを使用して RAID のようなシステムを作成していると言う人もいますが、これはばかげているように思えます。EBS と比較して、Microsoft Azure ドライブの信頼性はどの程度ですか?

  3. EBS と Microsoft Azure ドライブの両方でスナップショットを作成できると思います。スナップショットはバックアップに使用したり、VM インスタンスにマウントして元のボリュームを変更せずに変更したりできます。これは、複数のインスタンスで実行されている Web サイトをアップグレードする合理的な方法ですか (例: スナップショットを作成し、変更をデプロイし、すべてのインスタンスで読み取り専用としてマウントします)。

これらは私が持っていた基本的な質問にすぎませんが、Amazon EBS と Microsoft Azure Drives の経験がある方からのご意見をお待ちしております.

4

1 に答える 1

6

ページブロブを使用してAzureドライブを作成する方法について詳しく説明しているWindowsAzureドライブのホワイトペーパーを読むことで、いくつかの質問に答えることができました。これは、次のように記載されているWindowsAzureストレージSLAの対象となる必要があることを意味します。

Windows Azureには、コンピューティングとストレージ用に別々のSLAがあります。コンピューティングの場合、異なる障害ドメインに2つ以上のロールインスタンスをデプロイし、ドメインをアップグレードすると、インターネットに面するロールが少なくとも99.95％の時間外部接続できることを保証します。さらに、個々のロールインスタンスをすべて監視し、99.9％の時間で、ロールインスタンスのプロセスが実行されていないことを検出し、修正措置を開始することを保証します。

ストレージについては、データの追加、更新、読み取り、削除のために受け取った、正しくフォーマットされたリクエストを少なくとも99.9％の時間で正常に処理できることを保証します。また、ストレージアカウントがインターネットゲートウェイに接続できることも保証します。

これにより、 Web /ワーカーロールの場合は約26.28分、 Azureドライブへのアクセスが必要なストレージまたはロールの場合は52.56分の年間ダウンタイムウィンドウが得られます。Windows Azureには、Amazon AWSが提供するものと同様のリージョンがありますが、リージョン内には明確なアベイラビリティーゾーンがありません。代わりに、アップグレードドメインとフォールトドメインがあり、更新をロールアウトし、さまざまなハードウェアラックでロールインスタンスを見つけるために使用されます。障害ドメインはユーザーが構成できないため、より高いレベルの可用性が必要な場合は、別のリージョンで個別のサービスをセットアップする必要があります。

Amazon EBSドライブがどのように作成されるかについての同様の説明を見つけることができませんでしたが、実際にはAmazon S3に支えられておらず、代わりに別個のストレージシステムであるようです。Amazon S3 SLAは99.999999999％の耐久性と99.99％の可用性を提供しますが、EBSについて言及されているのは次のとおりです。

Amazon EBSボリュームは特定のアベイラビリティーゾーンに配置され、同じアベイラビリティーゾーンのインスタンスにアタッチできます。

各ストレージボリュームは、同じアベイラビリティーゾーン内で自動的に複製されます。これにより、単一のハードウェアコンポーネントの障害によるデータ損失が防止されます。

Amazon EBSは、AmazonS3に永続化されるボリュームのポイントインタイムスナップショットを作成する機能も提供します。これらのスナップショットは、新しいAmazon EBSボリュームの開始点として使用でき、長期的な耐久性のためにデータを保護します。同じスナップショットを使用して、必要な数のボリュームをインスタンス化できます。

また、EBSの年間故障率は、年間約4％で故障する一般的なハードドライブと比較して、0.1％〜0.5％と予想されることも示しています。EBSボリュームは完全に1つのアベイラビリティーゾーンに基づいているため、バックアップ用のスナップショットを作成することも重要です。

EBSボリュームには冗長性が組み込まれています。つまり、個々のドライブに障害が発生した場合や、その他の単一の障害が発生した場合でも、EBSボリュームに障害は発生しません。ただし、データを複数のアベイラビリティーゾーンに複製するS3ストレージほど冗長ではありません。EBSボリュームは完全に1つのアベイラビリティーゾーンに存在します。これは、S3に保存されているスナップショットバックアップを作成することが、長期的なデータ保護にとって重要であることを意味します。

最近のEBS/EC2の停止に関する事後レポートには、EBSのアーキテクチャに関する詳細が記載されており、トリガーが無効なネットワーク構成の変更であったことが示されています。この変更により、多くのボリュームがミラーとの関連付けが解除されましquickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica.た。これは、いくつかの競合状態、不適切なバックオフタイムアウト、およびソフトウェアのバグと相まって、複数のアベイラビリティーゾーンに影響を与える長期の停止を引き起こしました。Amazonは、EBSコントロールプレーンを個々のアベイラビリティーゾーンでの障害に対してより耐性にすることを含め、これが将来発生するのを防ぐために多くのアクションを実行していると述べています。

結局、障害を予測して許容するように設計されたシステムは、AWSの停止による影響がはるかに少なくなりました。少なくとも、AzureドライブまたはAmazon EBSを使用するシステムは、提供されているスナップショット機能を使用して定期的なバックアップを作成する必要があり、スナップショットを別のリージョンまたは完全に別のストレージプロバイダーに出荷することを検討することもできます。

于 2011-04-29T21:26:17.130 に答える