基盤となる OS/VM で実行される計画的なメンテナンス中にサイトを利用できるようにするには、いくつのインスタンスを構成する必要がありますか。
Web ロールの可用性モデルは理解していますが、Azure上のWeb サイトでも同じかどうかはわかりません。
Web ロールでは、Microsoft から SLA を取得し、サイトが定期的に利用できるようにするために、別々のアップグレード ドメインで少なくとも 2 つのインスタンスを構成する必要があります。これにより、Microsoft が基盤となる OS のメンテナンス (OS イメージの新しいバージョンへの更新など) を実行する間、サイトは引き続き利用可能になります。
ウェブサイトの同等の話は何ですか? Web サイトの 2 つのインスタンスが必要ですか、それとも Microsoft がメンテナンスを実行する前に積極的に新しい VM にサイトを移動しますか (Web サイトは Web ロールよりも「管理されている」ため、これを実行する可能性があるようです) )?
Free、Shared、Reserved のWeb サイト間で答えは変わりますか?
突然の計画外のダウンタイムが発生した場合、単一のインスタンスを使用すると、新しいノードで再起動するまでサイトが利用できなくなることを理解しています. 私のボリュームの少ない趣味のサイトでは、それについて心配する必要はありません。私がより関心を持っているのは、VM またはホスト ハードウェアの計画外の障害よりもはるかに一般的な定期的な計画的なメンテナンス アクティビティです。
明確化のために編集:明らかに、2 つ (またはそれ以上) のリザーブド インスタンスを使用することが、高可用性を実現するための最良の選択肢になりますが、月額 120 ドル弱という趣味のサイトには法外なコストがかかります。私の質問は、単一の共有インスタンスまたは予約済みインスタンスで、計画メンテナンスのために定期的なダウンタイムが発生するかどうかです。誰かがこれに関する具体的な情報を持っているかどうか特に疑問に思っています (見逃した可能性のあるブログ投稿から、またはマイクロソフトのサポート担当者との電話などから)。おそらく答えは、「マイクロソフトはまだプレビュー以外でどのように機能するかを明確にしていないため、誰にもわかりません」です。
また、「高可用性」という用語にとらわれたくありません。「低可用性ではない」を探しているだけだと思います。結局のところ、それはただの趣味のサイトです。