クラウドストレージ：APIアップデート

ニュースを急いで発表しています。クラウドストレージAPIを書き直しました。 現在、すべてがOpen Platform Swift on Goのいくつかのコンポーネントの実装であるHummingbirdという新しいプラットフォームのおかげで、はるかに安定して高速に動作します。 この記事では、 Hummingbirdをどのように実装したか、どのような問題を解決できたかについて説明します。







OpenStack Swiftオブジェクトストレージモデル



OpenStack Swiftオブジェクトストレージモデルには、いくつかの統合されたエンティティが含まれています。

• エンドユーザーから特定のデータセットを受信するプロキシサーバーは、リポジトリの他のコンポーネントにサービスリクエストを実行し、最終的に正しい答えを生成して送信します。
• アカウントおよびコンテナサーバー。 ここで、これら2つのサービスを組み合わせます。 原則として非常に似ています-それぞれがメタデータを保存し、コンテナ（アカウントサーバー）とファイル（コンテナーサーバー）のリストを個別のsqlite-basesに保存し、リクエストに応じてこのデータを発行します。
• オブジェクトサーバー。実際には、ユーザーファイル（および拡張属性のファイルレベルメタデータ）を保存します。 これは最も原始的な抽象化レベルです。特定のパーティションに書き込まれたオブジェクト（ファイル形式）のみがあります。

これらの各コンポーネントは個別のデーモンです。 すべてのデーモンは、クラスタ内のオブジェクトの場所を決定するハッシュテーブルと呼ばれるリングを使用して、クラスタ内で結合されます。 リングは別のプロセス（リングビルダー）によって作成され、クラスターのすべてのノードに配布されます。 クラスター内のオブジェクトのレプリカの数を設定して、フォールトトレランス（通常、異なるオブジェクトに各オブジェクトの3つのコピーを保存することをお勧めします）、パーティションの数（Swiftの内部構造）、ゾーンおよび地域ごとのデバイスの分布を設定します。 リングは、メインデバイスが利用できない場合にデータが注がれるいわゆるハンドオフデバイスのリストも提供します。



すべてのストレージコンポーネントを詳細に検討してみましょう。



プロキシ



最初は標準のswift-proxyを使用し、その後、負荷が増加し、独自のコードが大きくなったときに、これをすべてgeventとgunicornに転送し 、後にgunicornをuwsgiに置き換えました。 これらのすべてのソリューションは特に効果的ではなく、プロキシに関連する待ち時間は非常に長く、承認されたトラフィックを処理するためにますます多くのサーバーを使用する必要がありました。 Python自体は非常に遅いです。 その結果、このトラフィックはすべて12台のマシンで処理する必要がありました（現在、パブリックとプライベートの両方のすべてのトラフィックは3台のサーバーでのみ処理されています）。



これらすべての緩和措置の後、プロキシサーバーを書き直しました。 Hummingbirdプロジェクトのプロトタイプをベースとして、すべてのユーザー機能を実装するミドルウェアを追加しました。これらは、承認、割り当て、静的サイト、シンボリックリンク、大きなセグメントオブジェクト（動的および静的）、追加ドメイン、バージョニングなど さらに、いくつかの特別な機能が動作するように、個別のエンドポイントを実装しました-これは、ドメイン、SSL証明書、およびサブユーザーのセットアップです。 ミドルウェアチェーンを形成する手段として、リクエストコンテキスト-gorilla / contextにグローバル変数を格納するために、justinas / alice（https://github.com/justinas/alice）を使用します 。



OpenStack Swiftサービスにリクエストを送信するには、directclientコンポーネントが使用されます。これは、すべてのストレージコンポーネントへの完全なアクセス権を持っています。 特に、アカウント、コンテナ、オブジェクトのレベルのメタデータのキャッシュを積極的に使用しています。 このメタデータはリクエストコンテキストに含まれます。 それらは、それ以上の処理を決定するために必要です。 リポジトリへのサービスリクエストが多すぎないように、このデータをmemcacheキャッシュに保持します。 したがって、プロキシサーバーはリクエストを受信し、そのコンテキストを形成し、さまざまなレイヤー（ミドルウェア）を通過します。そのうちの1つは「このリクエストは私のためです！」と言う必要があります。 この層がリクエストを処理し、ユーザーに回答を返します。



ストアへのすべての無許可リクエストは、最初にキャッシュプロキシを通過します。キャッシュプロキシには、Apache Trafficserverを選択しました。

標準のキャッシュポリシーは、キャッシュ内のオブジェクトの場所がかなり長いことを意味するため（そうでない場合、キャッシュは役に立たない）、キャッシュをクリアするために別のデーモンを作成しました。 プロキシからPUT要求イベントを受信し、変更されたオブジェクトのすべての名前のキャッシュをクリアします（リポジトリ内の各オブジェクトには少なくとも2つの名前があります：userId.selcdn.ruおよびuserId.selcdn.com。ユーザーはドメインをコンテナに添付することもできます。キャッシュをクリアする必要もあります）。



アカウントとコンテナ



リポジトリ内のアカウントレイヤーは次のようになります：各ユーザーに対して個別のsqliteデータベースが作成され、グローバルメタデータ（アカウントクォータ、TempURLなどのキー）のセット、およびこのユーザーのコンテナーのリストが保存されます。 ユーザーあたりのコンテナの数は数十億個ではないため、データベースのサイズは小さく、すぐに複製されます。

一般的に、アカウントは問題なく機能し、問題はありません。進歩的な人類は皆、それらを愛しています。



コンテナでは、状況は異なります。 技術的な観点から見ると、これらはまったく同じsqliteベースですが、これらのデータベースには、1人のユーザーのコンテナーの小さなリストではなく、特定のコンテナーのメタデータとその中のファイルのリストが含まれています。 一部のお客様は、1つのコンテナに最大1億個のファイルを保存しています。 このような大規模なsqliteデータベースのクエリは低速であり、レプリケーション（非同期レコードの可用性を考慮した場合）ははるかに複雑です。



もちろん、コンテナ用のsqliteストレージは何かで置き換えることができます-しかし、何で？ MongoDBとCassandraに基づいてアカウントサーバーとコンテナサーバーのテストバージョンを作成しましたが、このようなソリューションはすべて、中央集中型データベースに「結び付けられ」、水平スケーリングの観点からは成功とは言えません。 時間とともにクライアントとファイルが増えているため、数十億のレコードを持つ1つの巨大なデータベースを使用するよりも、多数の小さなデータベースにデータを保存する方が望ましいと思われます。



自動コンテナシャーディングを実装することは不必要ではありません。巨大なコンテナをいくつかのsqliteベースに分割する機会があれば、一般的に素晴らしいことです。

シャーディングの詳細については、 こちらをご覧ください 。 ご覧のとおり、すべてが進行中です。



コンテナサーバーに直接関連するもう1つの機能は、オブジェクトの有効期限を制限することです。 X-Delete-AtまたはX-Delete-Afterヘッダーを使用して、オブジェクトストレージオブジェクトが削除されるまでの期間を設定できます。 これらのヘッダーは、オブジェクトの作成時（PUT要求）、またはメタデータの変更時（POST要求）に等しく送信できます。 ただし、このプロセスの現在の実装は、私たちが望むほど良く見えません。 実際、最初はこの機能は既存のOpenStack Swiftインフラストラクチャに対して可能な限り少ない修正を加えるような方法で実装されていました。 そして、ここでは最も簡単な方法で進めました。有効期間が限られているすべてのオブジェクトのアドレスを特別な「.expiring_objects」アカウントに入れ、object-expirerという別のデーモンを使用してこのアカウントを定期的に表示することにしました。 その後、さらに2つの問題がありました。

• 最初はサービスアカウントです。 これで、指定されたヘッダーの1つを持つオブジェクトに対してPUT / POSTリクエストを行うと、名前がタイムスタンプ（unixタイムスタンプ）であるこのアカウントにコンテナが作成されます。 これらのコンテナでは、タイムスタンプ形式の名前と、対応する実際のオブジェクトへのフルパスを使用して、擬似オブジェクトが作成されます。 これを行うには、コンテナサーバーにアクセスしてデータベースにエントリを作成する特別な関数を使用します。 オブジェクトサーバーはまったく関与しません。 したがって、オブジェクトの保存期間を制限する機能を積極的に使用すると、コンテナサーバーの負荷が大幅に増加します。
• 2番目は、object-expirerデーモンに関連付けられています。 このデーモンは、定期的に疑似オブジェクトの膨大なリストを通過し、タイムスタンプをチェックし、期限切れのファイルを削除する要求を送信します。 その主な欠点は、極端に遅い速度です。 このため、オブジェクトが実際に削除されることがよくありますが、コンテナデータベース内の対応するエントリはまだ削除されていないため、コンテナのリストに表示されます。

私たちの実践では、典型的な状況は、2億を超えるファイルが削除キューにあり、オブジェクト有効期限がそのタスクに対処できない場合です。 したがって、Goで記述された独自のデーモンを作成する必要がありました。



かなり長い間議論されてきた解決策があり、すぐに実装されることを願っています。



何で構成されていますか？ コンテナレプリケータが期限切れのファイルを削除できるようにする追加のフィールドがコンテナデータベーススキーマに表示されます。 これにより、既に削除されたオブジェクトに関するレコードのコンテナデータベース内の存在に関する問題が解決され、オブジェクト監査は期限切れオブジェクトのファイルを削除します。 これにより、オブジェクト有効期限を完全に放棄することもできます。現時点では、マルチモスクワと同じアタビズムです。



オブジェクト



機能レベルは、OpenStack Swiftの最も簡単な部分です。 このレベルでは、オブジェクト（ファイル）のバイトセットと、これらのファイルに対する特定の操作セット（書き込み、読み取り、削除）のみがあります。 オブジェクトを操作するには、デーモンの標準セットが使用されます。

• オブジェクトのサーバー（オブジェクトサーバー）-プロキシサーバーから要求を受信し、実際のファイルシステムのオブジェクトを配置/提供します。
• オブジェクトレプリケーター（オブジェクトレプリケーター）-rsyncの上にレプリケーションのロジックを実装します。
• オブジェクト監査（オブジェクト監査）-オブジェクトとその属性の整合性をチェックし、破損したオブジェクトを隔離して、レプリケーターが別のソースから正しいコピーを復元できるようにします。
• 修正プログラム（オブジェクト更新プログラム）-アカウントおよびコンテナのデータベースを更新する遅延操作を実行するように設計されています。 このような操作は、たとえば、sqliteデータベースのブロックに関連するタイムアウトが原因で発生する場合があります。

とてもシンプルに見えますよね？ ただし、このレイヤーには、リリースからリリースへと移行するいくつかの重要な問題があります。

1. rsync上でのオブジェクトの複製が非常に遅い（非常に遅い）。 小さなクラスターでこれに耐えることができる場合、数十億個のオブジェクトに到達した後、すべてが非常に悲しいように見えます。 Rsyncは、プッシュレプリケーションモデルを想定しています。オブジェクトレプリケーションサービスは、そのノード上のファイルを調べ、このファイルがあるはずの他のすべてのノードにこれらのファイルをプッシュしようとします。 これはもはやそれほど単純なプロセスではありません。特に、パフォーマンスを向上させるためにパーティションの追加ハッシュが使用されます。 このすべての詳細については、 こちらをご覧ください。
2. オブジェクトサーバーの定期的な問題。ディスクの1つでI / O操作がハングしたときに簡単にブロックできます。 これは、リクエストへの応答時間の急激な増加に現れます。 なぜこれが起こっているのですか？ 大規模なクラスターでは、完全にすべてのサーバーが実行され、すべてのディスクがマウントされ、すべてのファイルシステムがアクセス可能な理想的な状況を常に達成できるとは限りません。 オブジェクトサーバー内のディスクは定期的に「ハング」します（オブジェクトには小さなiops制限のある通常のhddが使用されます）。 標準のオブジェクトサーバーには、操作を単一のディスクに分離するメカニズムがありません。 これにより、特に多数のタイムアウトが発生します。

幸いなことに、Swiftの代替が最近登場しました。これにより、上記の問題をすべて効果的に解決できます。 これは上で述べたハミングバードと同じです。 次のセクションでは、これについてさらに詳しく説明します。



Swiftの問題を解決する試みとしてのハチドリ



最近、RackspaceはOpenStack Swiftの改良とGoでの書き直しの作業を開始しました。 これは、サーバー、レプリケーター、オーディターなど、すぐに使用できるオブジェクトのレイヤーです。 ストレージポリシーはまだサポートされていませんが、ストレージでは使用されていません。 オブジェクトに関連付けられたデーモンには、コレクター（オブジェクト更新プログラム）だけがありません。



一般に、hummingbirdは公式のOpenStackリポジトリの機能ブランチです。このプロジェクトは現在活発に開発されており、まもなくマスター（おそらく）に含まれます。開発に参加できます-github.com/openstack/swift/tree/feature/hummingbird 。



ハミングバードがスウィフトよりも優れているのはなぜですか？



まず、Hummingbirdのレプリケーションロジックが変更されました。 レプリケーターは、ローカルファイルシステム内のすべてのファイルをバイパスし、すべてのノードに要求を送信します：「これが必要ですか？」（そのような要求のルーティングを簡素化するために、REPCONNメソッドが使用されます）。 応答に新しいバージョンのファイルがあると言われた場合、ローカルファイルは削除されます。 このファイルがどこかで欠落している場合、欠落したコピーが作成されます。 ファイルが既に削除されており、新しいタイムスタンプを持つ廃棄ファイルがどこかで見つかった場合、ローカルファイルはすぐに削除されます。



ここでは、廃棄ファイルとは何かを説明する必要があります。 これは、削除されたときにオブジェクトの場所に配置される空のファイルです。



なぜそのようなファイルが必要なのですか？ 大規模な分散ストレージの場合、DELETE要求を送信するときに、オブジェクトのすべてのコピーがすぐに削除されることを保証できません。この種の操作では、n個の要求を受信した後の正常な削除に関する応答をユーザーに送信するためです（nはクォーラムに対応） 3コピーの場合-2つの回答が得られます）。 一部のデバイスはさまざまな理由で使用できない場合があるため（たとえば、機器のスケジュールされた作業）、これは意図的に行われます。 当然、これらのデバイス上のファイルのコピーは削除されません。

さらに、デバイスがクラスターに戻った後、ファイルは使用可能になります。 したがって、削除すると、オブジェクトは名前に現在のタイムスタンプを持つ空のファイルに置き換えられます。 サーバーのポーリング中に、レプリケーターが2つのトゥームストーンファイルを検出し、新しいタイムスタンプと、ファイルの1つのコピーに古い最終変更がある場合でも、オブジェクトは削除されており、残りのコピーも削除する必要があります。



オブジェクトサーバーの場合も同じです。ディスクは分離されており、ディスクへの競合接続を制限するセマフォがあります。 何らかの理由でディスクがリクエストキューを「フリーズ」またはオーバーフローした場合、単に別のノードに移動できます。



Hummingbirdプロジェクトは正常に開発されています。 すぐに公式にOpenStackに含まれることを期待しましょう。



クラウドストレージクラスター全体をHummingbirdにアップグレードしました。 これにより、オブジェクトのサーバーからの応答の平均待機時間が減少し、エラーがはるかに少なくなりました。 上記のように、Hummingbirdのプロトタイプに基づいて独自のプロキシサーバーを使用します。 機能層もHummingbirdのデーモンのセットに置き換えられました。

標準のOpenStack Swiftのコンポーネントのうち、アカウントとコンテナのレイヤーに関連付けられているデーモンだけでなく、デーモン修正プログラム（オブジェクト更新プログラム）も使用されます。



おわりに



この記事では、ハミングバードと、その助けを借りて解決できる問題について説明しました。 ご質問があれば、コメントでお答えします。



新しいプラットフォームへの移行のおかげで、ストレージAPIの機能範囲を大幅に拡大することができました。 ユーザー管理、ドメイン、SSL証明書などの新機能が登場しました。 近い将来、更新されたAPIのドキュメントをコントロールパネルに掲載し、すべての革新について詳しくは別の記事で説明します。