ファイルシステムの冗長性+速度
いくつかの入力を探し、誰かがこの問題を解決策で克服した場合、彼らは自信を持っています。
フォールトトレラントなWeb環境のセットアップを検討しています。したがって、セットアップはロードバランサーの背後にあるいくつかのノードです。これで、Web開発者は1つのサーバーにSSHで接続して、コードなどを編集できます。
私はglusterfsについて考えていますが、ドキュメントルートとしてglusterfsファイルシステムを配置すると、Webサーバーが提供できるページが約20〜30％減少します。私はイーサネット上にいるだけで、インフィバンドなどはいないので、これを期待しています。
だから私はglusterfs + inotifyの使用を考えていました。そのため、docrootとglusterマウントの変更を監視し、変更されたファイル/ディレクトリに対してrsyncを実行するinotifyスクリプトを実行しています。このように、Apacheはglusterではなくローカルディスクから提供できますが、クラスター化されたファイルシステムを介して提供されているという効果があります。
それに関する私の唯一の問題は、2つのinotifyスクリプトを実行する必要があることです。実行しているファイル数に対して、約700メガバイトのRAM）を使用していたすべてのinotifyウォッチャーを追加します。両方とも。
それで、誰かが何かアドバイスや指針を持っていますか？
ありがとう！
[〜＃〜]編集[〜＃〜]
それをウェブホストのように考えてください。クライアントは1つのサーバーにSSH接続しますが、クライアントが作成/編集/削除するファイルは他のすべてのノードにあります
逆もまた真である必要があります。Webサーバーがファイルを作成する場合、それらもすべてのノードに存在する必要があります。
遅すぎるので、ストレートrsyncがスローされます。
うわー、私は過去の仕事へのフラッシュバックを持っています、そこではあなたが説明している正確な理論的根拠のためにGFSが使われました。シナリオ：2000を超える顧客が多数の大規模クラウドでアプリを実行しています。
基本的に、自分がやりたいと思うことはできません。ローカルファイルシステムの速度に近い速度で動作するクラスター化されたファイルシステムまたはネットワークファイルシステムを取得することはできません。少しの間、強調しておきます：[〜＃〜]できません[〜＃〜]。あなたができると思うなら、あなたは自分自身をだましているのです。他の誰かができると言ったら、彼らは嘘をついています。単純な数学です。ディスク速度+コントローラーIO +ネットワーク遅延+クラスターfu はディスク速度+コントローラーIOよりも大きい必要があります。
さて、あなたがこれを構築しているかもしれない理由と、あなたがしたいことが役に立たない理由まで：
- 展開の単純さ：1台のマシンに展開して、どこでも自動的に実行するのは簡単ではありません。--get this-にデプロイしているマシンは1つではありません。確かに、コードのインスタンスを1つだけコピーするだけでよいと思うかもしれませんが、さまざまな状況で実行する必要があるアプリサーバーごとの作業はたくさんあります。多くの場合、私は個人的に対処しなければならず、共有ファイルシステムにインストールすると、展開プロセスが以前よりも複雑になりました。 「複数のマシンに展開するにはどうすればよいですか」という質問に対する正解は、「自動展開」です。
- 信頼性のためのクラスタリング：これは私にとって冗談の境界です。最新のハードウェアは非常に信頼性が高く、クラスタリングテクノロジーは非常に信頼性が低いため、クラスタリング（特にクラスタリングファイルシステム）[〜＃〜]増加[〜＃〜] ダウンタイム。そのトピックに関するホワイトペーパーに十分なデータがあります。さて、「EMC SAN 4年間、生産停止なしで稼働している」」と言う人もいますが、その信頼性に対していくら払ったのでしょうか。誰も聞いたことがありません。そのような信頼性は（TCOベースで）7桁未満で得られ、そこにも多くの専門知識のコストがかかりました。この質問をしているという事実は、しないでくださいその専門知識を持っているので、7つの数字を下に置くことも考えていないに違いありません。
- 容量のクラスタリング：これは冒頭陳述に戻ります-あらゆる種類のクラスター化されたファイルシステムはローカルのものよりも低速です。クラスター化されたファイルシステムまたはネットワークファイルシステムから大量のパフォーマンスを抽出しようとすると、失われた原因になります。それはあなたを怒らせるでしょう（それは確かに私のためにトリックをしました）。
私は画面などでネガティブなネリーになっているので、できるは何ができますか？ええと、それは基本的にあなたの顧客を個別のレベルで助けることに帰着します。
無限の規模で、万能型のホスティングインフラストラクチャを構築することはできません。それは私のGFSを愛する過去の雇用主がやろうとしたことであり、ガムではそれはうまくいきませんでした、そして私はそれが現在利用可能な開発と運用技術ではできないと確信しています。
代わりに、少し時間をかけて顧客の要件を評価し、顧客の要件を満たすソリューションに向けて支援してください。必ずしもすべての顧客を完全に分析する必要はありません。最初の数回が終わると、（うまくいけば）パターンが出現し始めます。これにより、さまざまな「標準」ソリューションに進むことができます。 「OK、要件F、P、およびAleph-1があるので、ソリューションZZ-23-plural-Z-alphaを使用するのが最善です。このソリューションの展開に関する包括的なドキュメントセットは次のとおりです。 、およびこのソリューションを自分で実装できない場合のカスタムコンサルティングの価格は、一番下にあります。」.
詳細については、リストするには多すぎますが、いくつかのヒントを紹介します。
- コードを各アプリサーバーに個別にデプロイします。
- 本当に共有動的アセットを使用する必要がある場合は、NFSを使用してください。それはばかげて単純で、はるかに低い破損率を持っています。共有 [〜＃〜]アセット[〜＃〜] -コードでも、構成でも、ログでも、顧客提供のアセット。
- ただし、NFSは永遠に拡張するわけではありません（NetAppの宣伝にもかかわらず）。ある時点で、顧客は別の場所に移動する必要があり（その例として、私は 前に を指定しました）、よりスケーラブルな場所への移動を支援できます。優れたドキュメントとその他の既成の支援によるソリューション。
- これがファイアアンドフォーゲットビジネスになる可能性があると考えているのなら、あなたは間違っています。あなたはコモディティウェブホスティング（すべての良い点-メンテナンスが少ない-と悪い点-マージンがない-それが意味する）と特殊なウェブホスティング（あなたがやろうとしていることです）を持っています、後者はメンテナンスが高いです（ただし、それに応じてマージンも高くなります）。
@Zypherのコメントを読んでください。それらの言葉の知恵を理解するまで何度も読んで、光を見て、開発者を本番サーバーから適切なサンドボックスに追いかけてください。
私の先のとがった棒を借りることができます。 :-)
その観点から質問を再構成します。「Webサーバー上のコードの一貫性を保つにはどうすればよいですか？」.
回答： puppet （または Chef ）、 radmind 、またはそこにある多くの素晴らしい構成/デプロイメントシステムのいずれか。
これらのツールは、目標を達成するためのはるかに簡単な方法を提供し、RAM/CPUの使用量を大幅に削減し、すべてのノードで一貫性を保証するように設定できます。
回答のこの部分は、元の質問の編集に基づいて取り下げられました
私が考えることができる解決策は本当に1つだけです。それは、SAN（またはNASデバイスがNFS経由でファイルを提供する））です。
このルートをお勧めする理由は、各サーバーで作成されたファイルを他のすべてのサーバーで使用できるようにする必要があるためです。大規模なN-way同期を行うと、扱いにくく遅くなります。 SANに集中することで、パフォーマンスが向上し、冗長性が向上し（SANは、安くなければかなり防弾になります）、ニーズの増加に応じて簡単にスケールアップできます。
欠点がないわけではありません。冗長ファブリックを使用してミラー化された冗長SANのペアを実行しない限り、単一障害点が発生します。 SANも安価ではなく、冗長性によって費用が増えるだけです。
開発者が何かを壊したときに電話をかけないことが保証されていない限り、開発者を本番ボックスから遠ざける必要がなくなるわけではないことに注意してください。少なくとも、あなたは彼らがあなたから開発環境を借りることを強く提案するべきです（明らかに合理的な利益で-の費用を支払うのを助ける何かSAN ...）