優れたHighload ++会議に参加した人たちは、とりわけ、ストレージの配置に関するレポートを聞く機会がありました。 私たちが話したことの要約は、Habrahabrの著名な聴衆に提供します。
クラウドの本質は、要求に応じて特定のタイプの必要な量のリソースを迅速に取得できることです。 おなじみのデスクトップがあります—ディスクスペース、プロセッサパワー、RAM。 1つ、もう1つ、3つ目（たとえば、256メガバイトのメモリと数百ギガバイトのディスクを備えた仮想マシンを取得した）を少し取った後、ユーザーはこれらのギガバイトを数千の小さなファイルの形で配布したいと考えています。特別な「クラウドマジック」については、大げさなマーケティング担当者は彼に歌いませんでした。 実際、サービスを設計する際に留意する必要がある他の、あまり馴染みのないタイプのリソースがあります。たとえば、コンテンツ配布や負荷分散リソースなどです。
上記の種類のエンティティを使用して、従来のLAMPスタックを使用して、「クラウドマジック」を実装し、負荷の増加に伴うスケーリングを容易にするソリューションアーキテクチャを構築できます。 このようなスキームを実装するために必要なものを体系的に実装しています。
そのため、たとえば、ご存知のように通常のMySQLを使用するデータベースサーバーは水平方向にスケーリングするのが難しいため、垂直方向にスケーリングすることは理にかなっています。 理想的にはロードバランサーの背後にあるアプリケーションサーバーにアクセスするアプリケーションサーバーを水平方向にスケーリングし、 APIを使用してクローンコピーを生成できます 。 正確なクローンを使用できるようにするために、この目的のために特別に作成されたリポジトリを介して静的情報を配布することは理にかなっています。これにより、コンテンツの更新に追いついていないことが多い同期を取りません。
そこで、リポジトリを作成するタスクを設定しました。
- 信頼性のあるデータの保存。
- シンプルなデータ管理-APIを含む、
プログラムコードから使用する必要があるため。 - HTTP経由で「ホット」コンテンツを迅速に配信できます。
- 最も経験のないユーザー（FTP、FUSE）に馴染みのない対話のインターフェース。 地方文化センターのサイトのコンテンツマネージャーは、リポジトリにファイルをアップロードできる必要があります（はい、そのようなクライアントもいます）。
車輪を再発明しないことに決めたので、ストレージとしてOpenstack Swiftを選択しました 。これは、Rackspaceの西洋の同僚が使用しているのと同じストレージです。 写真は彼のデバイスを非常によく説明しています。
インターネットからのクライアントが認証ノードに来て、そこでトークンを提示し、トークンに応じて、ストレージの特定の部分へのアクセスを許可されます。 ストレージはフラットです：ディレクトリ構造はファイルのメタ属性を使用して設定されます（Swiftのメタ属性は一般的に非常に豊富なツールを提供します-このような関心がある場合、これについて詳しく説明できます）。
始めるために、Pacemakerを実行しているフロントエンドでSwiftプロキシを使用したSwiftのみに基づいたソリューションを試しました。
ソリューションは機能していますが、フロントエンドの1秒あたり400リクエストで既にプロセッサに沈み始めました。これは、私たちの条件ではまったく価値がありません。 したがって、NGINXをキャッシュプロキシとして追加することにしました。 SASディスクにキャッシュを配置しました。 nginxはデフォルトで複数のボリュームにキャッシュを保存する方法を知らないため、オーバーヘッドRAID 6で高価なSASディスクを使いたくなかったため、 catapに切り替えて 、すぐにマルチゾーンキャッシュを備えたnginxができました。 この構成により、フロントエンドは12,000件の要求に簡単に耐えることができ、プロセッサではなくフロントエンドのギガビットチャネルに置かれます。
その後、顧客の要望に応じたサービスの改良が始まりました。 まず第一に、次のような公開リンクが好きな人はいませんでした
http://cs1.clodo.ru/v1/CLODO_0563290e28e0d6f79a83ab6a84b42b7d/public/logo.gif-誰もがhttp://st.clodo.ru/logo.gifの精神で何かを望んでいました。 ドメインを接続する機能に加えて、URLからデフォルトのパブリックコンテナアドレスpublicを削除する必要がありました。 これは、小さな「nginx構成ファイルのプログラミング」によって解決されました。
次の問題はもっと徹底的です。 バックエンドから削除した後、ファイルはキャッシュに残り、しばらく利用できる場合があります。 Rackspaceの同僚は、この問題を解決する必要はないと考えています（そして実際、パブリックディストリビューションのすべての問題については、CDNパートナーと呼ばれています）。 私たちはこの問題を解決しようと決心しました-そして、悪魔ケシャがこれを手伝ってくれました。
Perlで作成され、FastCGIを介してnginxと対話する魅力的なデーモンであるキャッシュは、データが削除されるたびに無効になります。 同時に、彼はインテリジェンスを表示しようとします。たとえば、ディレクトリからファイルを削除するとき、キャッシュからファイルだけでなく、ディレクトリのリストも削除します。
ストレージ開発のいくつかの分野についてはすでに概説しています。
- クライアントがストレージのログを受信する可能性。
- メディアコンテンツの配信、ストリーミング。
- データセンター間の複製。
- pubcookiesの承認。
- すべてのSwiftプロキシ機能をnginxモジュールとして有効にします。
- HTTP 1.1の完全サポート。
現在のソリューションでは、1つのストレージセグメントで最大840 TBのディスクスペース、7 TBのキャッシュ、512 GBのキャッシュをRAMに保持できます。 これはすべて、データセンターで30ユニットに分割されます。 これらはすべて、Debian LiveでChefを使用して自動的にデプロイされ、PacemakerおよびClodoパネル（Openstackの外部で実装された操作-ドメインのリンクなど）によって制御されます。 原則として、同様のソリューションをごくわずかな鉄で構築し、独自の小さなプライベートクラウドに展開できます。
クラウドストレージは現在1か月稼働しており、これまでのところ、お客様は非常に使いやすく、その料金設定が最も簡単であるという事実を気に入っています。これは、1 GBを1時間、1ルーブルを1 GBの発信トラフィックに保存することができます。 リソースの負荷を増やしながら、プロセッサやRAMに予測不可能な負荷がかかることはありません。クラウドストレージのコストを見積もることは、従来のクラウドホスティングを使用するよりも桁違いに簡単です。
この投稿のPS写真は、クラウドストレージに投稿されています。