Microsoft Azureでは、 "高可用性" SLAを達成し、日常のメンテナンスのためにサイトが停止しないようにするために、アプリケーションが複数のデータセンターにまたがる2つのインスタンスを利用することが必要です。彼らは、どのペアのデータセンターが同時にメンテナンスに行くことは決してないだろうということさえあなたに話します。
これで問題ありませんが、同じVM上にMySQLデータベースを持つWordPressのようなアプリで実際にどのようにこれを簡単に行うのでしょうか。 2台の仮想マシン間で負荷分散を行うことに慣れていなくても、データベースの複製設定によって問題が解決することはありません。 2つのバージョンのデータが同期しなくなることは望ましくありません。 MySQLレプリケーションでは、ユーザーがスレーブインスタンスにアクセスした場合にマスターDBへの変更の同期に失敗するマスタースレーブ設定が必要になるようです。
この概念を誤解しているだけなのでしょうか。任意の助けは大歓迎です!
悪いニュース:Wordpressの中心的なオープンソースベースは、単一のサーバー上で実行されることについてかなりの数の仮定をしています(wp-content、ユーザーのアップロード、メディアライブラリなど)。
良いニュース:ほとんどすべてのクラウドプロバイダー(Azureを含む)には、これらの設計上の制限を回避するための抽象概念があります。
基本的には、次のような問題に対処します。
/ - (10.0.0.1 - eth0)wp1.domain.com(10.0.1.1 - eth2) (パブリックIP)wp.domain.com \ - ( 10.0.0.2 - eth1)wp2.domain.com(10.0.1.2 - eth3)
セッションの管理ユーザーにサイトへのログインを許可している場合。もしそうなら、あなたは彼らが将来のリクエストのすべてがそのサーバにルーティングされる(スティッキーセッション)か、セッションが他のメカニズムを通して管理されるのでそれらがアクセスするサーバに関係ないことを確実にする必要があります。 (たとえば、{ Zend Serverセッションクラスタリング を介して)。
管理者ログインの管理コンテンツを管理するために一部のユーザーにバックエンドへのログインを許可している場合(上記と同様)。
ALSO高可用性DBシステムの選択DBがクラッシュしてもシステム全体がダウンしても、2台のフロントエンドサーバーを使用しても意味がありません。 ClearDBを介したMySQL Master/Slaveレプリケーション、または{ SQL Serverを利用するためのプラグインによるWordPressの変更 } _を利用する必要があります。そのため、その{ ネイティブクラスタリングシステム を使用できます。これは、DB層を自分で管理したい場合には少なくとも4つのVMが必要であることを意味します(2 x App&2 x DB)。これは次のようになります。
/ - wp1.domain.com(10.0.1.1)\ --- /(10.0.1.3)db1.domain.com(10.0.2.3)\ wp .domain.com X | \ - wp2.domain.com(10.0.1.2)/ --- \(10.0.1.4)db2.domain.com(10.0.2.3)/
_ note _ - 信頼性の高いフェイルオーバーを保証し、システムのセキュリティを保護するために、他の通信ネットワークから分離されたプライベートチャネルを介して2つのデータベースノードを互いに接続するために通常THIRDネットワークサブネットが使用されます。アプリサーバーはデータベースと通信するために使用し、アプリサーバーは外部と通信するために使用します。
接続プーリングを有効にして、アプリケーションサーバーのデータベース接続のパフォーマンスと信頼性を最大化します。
W3 Total CacheやSuper CacheなどのCachingプラグインを利用して、フロントエンドサーバーの負荷を最小限に抑えます。
以下のガイドでは、上記の各課題にどのように対処できるかについて詳しく説明しています。 Azureでそれぞれを処理する方法はいくつかあります。したがって、それぞれの課題をどのように攻撃するかを決めてから、スタックを上下するときにそれぞれの選択肢が課す制約を処理します。