最近、Webサイトの負荷分散ソリューションをセットアップしました。私たちは約200のサイトをホストしており、ほとんどがカスタムアプリケーションを実行していますが、一部はwordpressブログ(ファイルをアップロード/削除できます)を実行しています。セットアップは基本です。
|-------------------> Apache1
|
HAProxy -|
|
|-------------------> Apache2
Apache1
を「マスター」として設定したので、それに加えられた変更のほとんどは、次のコマンドを使用して毎分Apache2
にrsyncされます。
rsync -av --delete Apache1:/var/www/html/ /var/www/html/
問題は、前述のように、ファイルがApache2
で追加/削除される場合があります。私がこれまでに思いついた唯一の解決策は、Apache1
で特定のディレクトリ(たとえばwp-content)内のすべてのファイルをそれ自体(削除ではなく)にrsyncしてから、すべてをApache2
にプッシュバックすることです。 。
これには欠点があり、主なものは次のとおりです。
Apache2
で削除された追加のファイルを取得します。両方のサーバーでファイルを追加、更新、削除できることを考慮して、2つ以上のWebサーバーの同期を維持する方法はありますか?
私は DRBDを使用したOCFS2 を使用しています。
DRBDリソース/etc/drbd.d/r0.res
:
resource r0 {
syncer { rate 1000M; }
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
startup { become-primary-on both; }
on s1 {
device /dev/drbd1;
disk /dev/sdc;
address ip1:7789;
meta-disk internal;
}
on s2 {
device /dev/drbd1;
disk /dev/xvdb2;
address ip2:7789;
meta-disk internal;
}
}
/dev/drbd1
はocfs2ファイルシステムとしてフォーマットされています。
/dev/drbd1 ocfs2 100660180 7427076 93233104 8% /data/webroot
Pacemakerを使用しないOCFS2の構成/etc/ocfs2/cluster.conf
:
node:
ip_port = 7777
ip_address = ip1
number = 0
name = s1
cluster = ocfs2
node:
ip_port = 7777
ip_address = ip2
number = 1
name = s2
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2
DRBDステータスはdrbd-overview
ユーティリティで確認できます。
# drbd-overview
1:r0 Connected Primary/Primary UpToDate/UpToDate C r---- /data/webroot ocfs2 96G 9.8G 87G 11%
または/proc/drbd
から:
cat /proc/drbd
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by [email protected], 2010-06-04 08:04:09
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
ns:953133955 nr:42207234 dw:1185526354 dr:62396241 al:230084 bm:5853 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
現在、rsyncも使用していますが、私はそれに夢中ではありません。
fileconveyor を実験してきました。これは、2つのサーバー間で同期するだけでなく、S3、Cloudfiles、またはその他のクラウドストレージとも同期できます。これにより、明らかに柔軟性が大幅に向上します。
現時点で共有できる構成設定はありませんが、表示されているものが気に入っています。
サーバーのセットアップでは使用していませんが、 nison を試してみてください。どちらかの側の変更を処理し、競合していないものを自動的に同期します。ホストは2つに制限されていると思いますので、現在のソリューションを超えて拡張することはできません。
2つのホストを超えてスケーリングする方法を私が知っている唯一の方法は、NFSまたは他の共有/分散ファイルシステムをセットアップすることです。
もう1つのオプションは、前面のWebサーバーとは別に、コンテンツの「信頼できる」レプリカを作成し、そのレプリカですべての更新と変更が行われるようにすることです。
次に、そのサーバーから、設定されたスケジュールで任意の数の前面サーバーに展開します。
はい、それはコンテンツの追加のコピーですが、いくつかの潜在的な利点があります。
1)更新がいつ公開されるかの制御
2)任意の数のサーバー間の多方向同期の処理の複雑さが軽減されます
3)正面の制作に影響を与えることなく、変更を加えてプレビューする機能。
他のオプションは、信頼性、パフォーマンス、およびスケーラビリティに必要な数のハードウェアに分散されたある種の共有ストレージです。
私はこれと同じ難問を抱えており、問題のアプリケーションの詳細に応じていくつかの解決策に出くわしました。
NFS: NFSまたはある種の共有ドライブは確かに機能しますが、私の場合は、システム全体をダウンさせる可能性のある1台のコンピューターのボトルネックが発生するため、回避したいと思いました。ロードバランシングの私の理由の強力な部分は冗長性であり、NFSはこれを方程式から外します。ただし、他のすべてのオプションが失敗した場合は、これだけが残っている可能性があります。
DBファイル:私がやろうとしていることのほとんどは、ファイルをデータベースに保存するアプリケーションを構築することです。そうすれば、クラスター化されたWebサーバーがデータを書き込む必要があることを心配する必要がありません。これは断然最善の解決策のように思われますが、ソフトウェアを開発していない場合は、多くの場合、オプションではありません。
DNS制御:少数のユーザーのみが使用する「admin」セクションがある一部のサイトまたはアプリケーション(wordpressブログなど))では、個別のDNSを使用することがありますマスターサーバーをポイントして、管理者が正しいサーバーにのみ書き込みを作成するようにします。いくつかの変更を加えるだけで、wp-adminをリダイレクトしてadmin dnsを使用できます。ここでの欠点は、ブログの前面の負荷が分散されたままであるということです。冗長で、管理セクションは1つのシステムに依存しています。ただし、ほとんどのブロガーにとって、これはおそらく問題ありません。
双方向rsync:私が避けようとしている最後のオプションは、多方向rsyncです。ここでの最大の問題は、ファイルが新しいファイルであるか(したがって、1つのサーバーにのみ表示される)、または削除されたファイルであるか(したがって、1つのサーバーにのみ表示される)をrsyncが認識できない場合です。通常、多方向のrsyncを実行する必要がある場合は、データが保存されている特定のフォルダーをターゲットにし、シンボリックリンクを使用して構造の残りの部分からデータを削除してから、削除せずに双方向でrsyncします。ほとんどのアプリケーションは、一時ファイルを作成している場合を除いて、ファイルを削除する必要はありません。一時ファイルは、とにかくサイト構造の外部に保存する必要があります。これはファイルの削除でも機能しますが、ファイルを保存する特定のディレクトリをターゲットにしようとします。
lSYNCDの現在の削除サポートを見てください
パスワードなしでssh認証を設定する https://www.shellhacks.com/ssh-login-without-password/
lsyncdを設定します(デフォルトではdebian/ubuntuリポジトリにも存在します) https://github.com/axkibe/lsyncd