地理的に異なる複数のサーバーで単一のWebサイトをホストする方法
現在、cPanel/WHMを使用して2台のサーバーがあります。 1つ目はロンドンでホストされているVPS（「国際」と呼びます）で、2つ目は私の国にある専用サーバー（「ローカル」と呼びます）です。
「ローカル」には無制限のローカル帯域幅がありますが、国際帯域幅は1Mbpsしかありません。
両方のサーバーで単一のWebサイト（または複数のWebサイト）をホストし、発信国に基づいて訪問者にサービスを提供する必要があります。つまり、訪問者が私の国から来た場合、データは「ローカル」から提供され、訪問者が他の国から来た場合、データは「国際」から提供されます。
どちらのタイプの訪問者もサーバーで読み取り/書き込み操作を実行できます。両方のサーバーでファイルとデータベースが更新されるため、両方のサーバー間でファイルとデータベースを同期する必要があります。
では、DNSと同期に関してこれをどのように実現できるでしょうか。または、簡単で可能なことは何ですか？誰かが私が実行しなければならないステップで私を導くことができますか？
最初の、シンプルで、わかりやすく、そして何よりも、堅牢なソリューションは、2台のサーバーを持つ計画をあきらめて、1台のマシンを実行することです。適切に中央の場所。ローカルサーバーから何もホストしない理由は理解していますが、国際帯域幅が制限されているため、ローカルサーバーの存在を必要とする質問には何も表示されません。
ローカルサーバーが必要な理由が純粋にパフォーマンス上の理由である場合は、ローカルの静的アセットサーバーを検討することを強くお勧めします。動的なものはすべてロンドンに送られます。 geoDNSは簡単ではありませんが、動的アセットとデータベースの堅牢なリアルタイム同期よりもはるかに簡単です。このメカニズムは、知覚される全体的なページ速度を向上させるために多くのサイト（これを含む）で使用されており、かなりうまく機能します。
ここではそうではなく、実際にdoに2台のサーバーが必要だとすると、計画に大きな欠陥があります。1Mbpsの国際帯域幅は同期トラフィックによってかなり飽和状態になります。あなたはあなたのサイトがあまり人気がないことを望みたいでしょう、さもなければあなたは苦痛の全世界にいるでしょう。
特定のレコードを提供するアドレスのサブセットが明確に定義されているため、DNSに対してかなり有利な立場にあります。おそらく、プロバイダーからネットブロックのリストを取得して、「ローカル、帯域幅無制限」トラフィックとしてカウントされるものと、「国際、1Mbps上限」トラフィックとしてカウントされるものを説明することができます。あなたのプロバイダーがそれを行うことができない場合、私は彼らに実際にどのように律速をしているのか尋ねるでしょう。どこかにあるリスト。最悪の場合、「このBGPリンクでアナウンスされたものはすべてローカル」に基づいて実行している場合でも、そのリンクのプレフィックスのリストを取得できるはずです。
したがって、DNSのものは、「Aレコード要求のwww.example.com、送信元アドレスがローカルプレフィックスのリストにある場合はlocalipを提供し、それ以外の場合はinternationalipを提供します」。特定のDNSサーバーに対してスクリプトを作成する方法はあなた次第です。 tinydnsを使用します。これは、できる限りすべてに使用しており、この特定のタスクで非常に優れているためです。
しかし、それは問題全体の約1％です。町のダイナミックな資産の側面には、はるかに大きな問題があります。
データベースは実際には（比較的）簡単なビットです。 MySQLとPostgreSQLはどちらもマルチマスターレプリケーションをサポートしているため、どちらかのデータベースへの書き込みは、もう一方のデータベースに（多かれ少なかれ）自動的にレプリケートされます。セットアップは簡単ではありません。ベジェサスを監視して、壊れたときを検出して修正する必要がありますが、は可能です。かなり標準化された方法。
一方、ファイルには、より多くのローカルインテリジェンスが必要です。これを機能させるには、レプリケーションが機能するようにファイルストレージを適切に設計する必要があります。あなたが削除をサポートする必要があると言うので、それはさらに面白いです。
本当に、定期的なrsyncはこれに対するあなたの親友です。物事の変更と削除の側面を一瞬無視して、ファイル名が両側で衝突しないことを確認した場合（すべてのファイル名の基礎としてUUIDまたはデータベースPKを使用すると、うまく機能します）、次のことができるはずです。それぞれの側からもう一方への定期的なrsync、およびそれぞれの側で作成されたすべての新しいファイルは、魔法のようにもう一方に表示されます。 rsyncを実行する頻度は、すべてが同期されるまでにどれだけの時間立つことができるかによって異なります。これは、実行する必要のある呼び出しです。また、アプリケーションは、（たとえば）DBレコードが同期されているが、ファイルが同期されていない場合をインテリジェントに処理する必要があります。
ブラインドを実行することはできないため、削除すると事態はさらに難しくなりますrsync -a --delete送信者が持っていないものはすべて受信者から削除されるため、大量のデータを失うのに最適な方法です。削除ログを用意して、時々それを実行し、反対側から削除したいと思います。それが魅力的でない場合は、両端に2つの別々のファイルシステム（1つは「ローカルデータ」用、もう1つは「もう一方の端のレプリカ」用）を使用して、アプリケーションから両方にアクセスするか、ユニオンファイルシステムレイヤーを使用して、Webサーバーからは1つのファイルシステムのように見せます。
変更は完全な悪夢です。リスクは両方のサーバーで同時に変更されることであり、その時点であなたはただ失敗します。ここで使用している一種の「結果整合性」モデル（地理的に分散した高遅延のレプリケーションシステムでは、これが唯一のオプションです）では、インフラストラクチャでこれを処理することはできません。レベル-これらの種類の問題に対処する方法を決定するには、アプリケーションで何らかの妥協を行う必要があります。ファイルシステムを追加専用ストアとして扱うことで状況を改善できます（ファイルを変更する場合は、新しいバージョンを作成し、新しいレコードを指すようにデータベースを更新します）が、データベースも結果整合性があるため、問題を完全に解決することはできません。ただし、少なくともデータベースが信頼できる唯一の情報源である場合は、正確性が保証されていなくても、一貫性が保証されます。これは、戦いの半分です。
そして、私はほぼすべてをカバーしていると思います。ただし、繰り返しになりますが、地理的に分散したサーバーを使用する必要がない場合、作業ははるかに簡単になります。 「かっこいい」という理由でこれを実装している場合は、キーボードから離れてください。かっこいいことをしたいのなら、自分の時間に、または科学実験としてやってください。あなたはあなたにオタクの持続勃起症を与えるものではなく、あなたの雇用者にとって最も効果的なことをするために支払われます。