25M 枚の写真を 4 つのサイズで保存する必要があります = 合計 100M のファイルです。ファイル サイズはファイルあたり 3Kb から 200kb の間で変化し、最初に使用されるストレージは約 14～15 TB です。
私たちの目標は、2〜4 台のサーバーでデータを利用できるようにし、ローカルの高速 Web サーバー (nginx または lighthttpd) でそれらを提供することです。そのためには、可能な限り多くのリクエスト/秒でサーバーを提供する必要があります。
私の計画は、データ用に 12x2TB (WD RE4) と Raid 6 (または冗長性のある FS??) を搭載した Intel の 2U サーバーケースを使用し、OS 用に 2x60GB SSD を使用することですが、これは良い方法でしょうか? 現在: 最もよく使用されるファイルのキャッシュに SSD SLC ドライブを使用できる Adaptec 5805ZQ を見つけましたが、これに関する提案はありますか?
どのような読み取りキャッシュ サイズを選択する必要がありますか?
このようなサーバーを 2 ～ 4 台用意する予定の場合、冗長性と負荷分散を実現する最善の方法は何でしょうか?
私たちの目標に関して、クラスターと分散 FS の長所と短所は何ですか?
答え1
これがグリーンフィールド開発であるならば、私は絶対にクラウドを使うだろう1 億個のファイルは大量のデータです。その冗長ストレージを Amazon S3 にオフロードすると、大幅な改善が期待できます。
1 億個のファイルについて話していることを考えれば、データセットの一部は「ホット」(頻繁に要求される) であり、大部分はコールドであると言っても過言ではないと思います。したがって、キャッシュが本当に必要です。
Amazon Web Services でこれを実行する方法の概要:
- 最初のレイヤー:Amazon が管理する Elastic Load Balancing と Amazon CloudWatch は、nginx または Apache を使用したいくつかの小さな EC2 インスタンスを監視します。これらのサーバーは静的な構成ファイルを持つ単なるロードバランサーなので、Cloudwatch はそれらを監視し、いずれかのインスタンスがクラッシュした場合に自動的に新しいインスタンスを生成します。
- 最初のレイヤーから:リクエスト URL (ファイル名) に基づく一貫した高速化キャッシュ サーバーのレイヤーに。ファイル名に基づいてハッシュ化することで、各ファイルが何度もキャッシュされないようにし (キャッシュ ヒット率を低下させます)、N 個のキャッシュ サーバーで各サーバーがアドレス空間の 1/N を処理するようにします。
- 2層目:キャッシュサーバー。キャッシュサーバーは、より多くのメモリを備えたEC2インスタンスであり、SquidまたはVarnishまたはApache トラフィック サーバーキャッシュがインストールされました。
- 第 2 層から: 従来の HTTP から Amazon S3 ファイル ストレージへ。
この設定は疎結合なので、水平方向に拡大するのは簡単(スケーリングの問題としては)。
速度は、ホット データとコールド データの比率に大きく依存します。ワークロードのほとんどがホットである場合、2 つの小さなロード バランサー EC2 と 2 つの高メモリ キャッシュ EC2 インスタンスだけで 10,000 リクエスト/秒をはるかに超える速度が実現しても不思議ではありません。
答え2
OS 自体に SSD を使うのは、30 秒も速く起動することに本当に興味がない限り、やりすぎです。小さな SAS ドライブを 2 つ入手するだけで十分でしょう。
キャッシュに関して、キャッシュの有用性はワーキング セットに依存します。つまり、イメージのリクエストがすべてのイメージに均等に分散されることが予想されるか、またはほとんどのリクエストが小さなサブセットに対して行われると予想されるかです。後者の場合、キャッシュは有用ですが、前者の場合、それほど有用ではありません。ディスク コントローラ上のキャッシュは、主に書き込みのキャッシュに有用であり (キャッシュが不揮発性の場合)、データベースなどの fsync() を多用するアプリケーションに役立ちます。イメージの提供の場合、利点はそれほど大きくないと思われます。
クラスター FS と分散 FS の問題は、セットアップがより複雑であり、特に分散 FS は「通常の」単一ノード FS よりも成熟していないことです。クラスター FS は通常、共有ストレージを意味し、単一障害点を回避するには比較的高価な SAN が必要になります。
代替案としては、HTTPでアクセス可能な分散型で複製されたキーバリューストレージを提供するAmazon S3に似たものを実行するクラスターをセットアップすることが考えられます。例:オープンスタックストレージ。
答え3
それらのアイテムがどのくらいの頻度で使用されるかによって大きく異なります。一度に非常にアクティブなアイテムの割合が小さいと予想される場合は、フロントエンドの処理に Varnish を使用し、nginx/lighttpd バックエンドから負荷分散することを検討してください。頻繁に使用される画像はキャッシュされるため、ディスク速度はそれほど重要ではありません。
ただし、画像が繰り返し要求されず、キャッシュによる大幅な向上が期待できない場合は、1 台または 2 台のサーバーで nginx/lighttpd を実行すると効果的です。配信する帯域幅の量も考慮する必要があります。データセットの小さなサブセットを 800 MB/秒で処理すれば、OS によって簡単にキャッシュされます。データセットの大きなサブセットを 800 MB/秒で処理すると、ディスクからデータを十分な速度で取得できず、IO ボトルネックが発生する可能性があります。その場合、システムを十分な数の部分に分割して IO 帯域幅を確保する必要があります。
RAID 6 を実行している場合でも、バックアップの代わりにはなりません。そのため、バックアップを行うための、またはフェイルオーバー ストレージ サーバーとして機能するための同様のマシンを予算に組み込んでください。
答え4
分散 FS ではなくカスタム クラスターを選択します。これは、理解しやすく、トラブルシューティングも簡単でありながら、機能し続けるためです。つまり、独自のクラスターの信頼性のトレードオフは明らかですが、分散 FS がデッド サーバーや障害のあるスイッチにどのように反応するかを把握するのは、それ自体がタスクです。
このような問題に対する可能な解決策は、写真アーカイブ全体をいくつかの部分に分割し (たとえば、2 つの部分)、URL で部分 ID を明示的に指定することです (たとえば、サブドメインにするか、正規表現で簡単に抽出できる GET パラメータにします)。そうすると、写真が格納された 4 つのストレージ サーバー (各部分に 2 つのサーバー) ができます。5 番目のサーバーを、負荷を分散してバランスをとるリバース プロキシとして使用します。5 つのサーバーはすべて lighttpd を実行できます。つまり、私が提案するのは、非常に愚かですが機能する (私が働いていた会社の場合 - 合計負荷は 1 秒あたり約 5000 リクエスト、ファイル サイズは 3 ～ 10 KB、一意のファイルの合計は 8 TB、24 のバックエンドからのサーバーですが、lighttpd ではなくカスタム HTTP デーモンを実行) ソリューションです。
ディスクと RAM については、各サーバーで 4 つの高速で安価な SATA ディスクで構成されたソフトウェア RAID-0 を使用しました (ディスクが故障しても、すべてのデータは他のサーバーのレプリカからコピーできます)。さらに、読み取りエラーが 1 回発生したらサーバー全体をオフラインにするカスタム ソリューションも使用しました。RAID-5 と RAID-6 は、1 つのディスクが故障しただけでも速度が非常に悪いため、使用しないでください。コンテンツ サーバーでは、大量の RAM (ディスク キャッシュとして) が必須です。24 GB 以上を探してください。それでも、30 分のウォームアップ時間に備えてください。リバース プロキシで lighttpd を使用する場合は、アップストリーム応答全体を可能な限り高速に RAM にバッファリングすること、およびダイヤルアップまたは GPRS で誰かにキャッシュされた写真をプッシュするのに時間がかかる可能性があることを考慮してください (その間、RAM にバッファリングする必要があります)。また、構成を同一にするためだけに 24 GB を使用しましたが、これが過剰かどうかはわかりません。リバース プロキシ上のメモリベースの HTTP キャッシュは必須ではありません (ホット イメージがある場合でも)。バックエンドの OS 提供のディスク キャッシュも同様に機能するためです。
アーカイブの同じ部分を提供するすべてのバックエンドが同じデータを持つようにするには、簡単です。写真を公開するときに、すべてのサーバーにコピーするだけです。次に、アーカイブの古い部分で rsync を使用して不一致を修正し、1 つのコピーをマスターにします。