ワンクラウド - Odnoklassniki のデータセンター レベルの OS

アロハ、皆さん！ 私の名前はオレグ・アナスタシエフです。Odnoklassniki のプラットフォーム チームで働いています。 そして、私以外にも、Odnoklassniki では多くのハードウェアが稼働しています。 当社には 500 つのデータセンターがあり、約 8 のラックに XNUMX 台以上のサーバーが設置されています。 ある時点で、新しい管理システムを導入すると、機器のロードがより効率的になり、アクセス管理が容易になり、コンピューティング リソースの（再）分配が自動化され、新しいサービスの立ち上げが加速され、対応が迅速化されることに気づきました。大規模な事故に。

何が起こったのでしょうか？

私と多数のハードウェアのほかに、このハードウェアを扱う人々もいます。 ネットワーク ソフトウェアをセットアップするネットワーカー。 インフラストラクチャの復元力を提供する管理者、つまり SRE。 と開発チームがあり、それぞれがポータルの機能の一部を担当します。 彼らが作成したソフトウェアは次のように動作します。

ユーザーリクエストはメインポータルの両方で受信されます www.ok.ru、その他、たとえば音楽 API の面でも。 ビジネス ロジックを処理するために、アプリケーション サーバーが呼び出されます。アプリケーション サーバーは、リクエストの処理時に、ワン グラフ (ソーシャル コネクションのグラフ)、ユーザー キャッシュ (ユーザー プロファイルのキャッシュ) など、必要な特殊なマイクロサービスを呼び出します。

これらの各サービスは多くのマシンにデプロイされており、それぞれのサービスにはモジュールの機能、その操作、および技術開発を担当する責任ある開発者がいます。 これらすべてのサービスはハードウェア サーバー上で実行され、最近までサーバーごとに XNUMX つのタスクを起動していました。つまり、特定のタスクに特化していました。

何故ですか？ このアプローチにはいくつかの利点がありました。

• 安心した 大量管理。 タスクにいくつかのライブラリといくつかの設定が必要だとします。 次に、サーバーは XNUMX つの特定のグループに割り当てられ、このグループの cfengine ポリシーが記述され (またはすでに記述されています)、この構成はこのグループ内のすべてのサーバーに一元的かつ自動的にロールアウトされます。
• 簡略化 診断法。 中央プロセッサの負荷の増加を見て、この負荷はこのハードウェア プロセッサで実行されるタスクによってのみ生成される可能性があることがわかったとします。 責任のある人物の捜索はすぐに終わります。
• 簡略化 モニタリング。 サーバーに何か問題がある場合、モニターがそれを報告するので、誰の責任なのかが正確にわかります。

複数のレプリカで構成されるサービスには、複数のサーバー (それぞれに XNUMX 台) が割り当てられます。 次に、サービスのコンピューティング リソースが非常に簡単に割り当てられます。つまり、サービスが持つサーバーの数、サービスが消費できるリソースの最大量です。 ここでいう「簡単」とは、使いやすいという意味ではなく、リソースの割り当てが手動で行われるという意味です。

このアプローチにより、次のことも可能になりました。 特殊なアイアン構成 このサーバー上で実行されているタスクの場合。 タスクが大量のデータを保存する場合は、4 個のディスクを備えたシャーシを備えた 38U サーバーを使用します。 タスクが純粋に計算に関するものであれば、より安価な 1U サーバーを購入できます。 これは計算効率が高いです。 とりわけ、このアプローチにより、XNUMX つのフレンドリーなソーシャル ネットワークに匹敵する負荷で XNUMX 分の XNUMX のマシンを使用できるようになります。

最も高価なものはサーバーであるという前提から進めば、コンピューティング リソースの使用におけるこのような効率は、経済効率も保証するはずです。 長い間、ハードウェアが最も高価であったため、私たちはハードウェアの信頼性要件を軽減するフォールト トレランス アルゴリズムを考案し、ハードウェアの価格を下げることに多大な努力を払ってきました。 そして今日では、サーバーの価格が決定的なものではなくなる段階に達しました。 最新のエキゾチックを考慮しない場合、ラック内のサーバーの特定の構成は重要ではありません。 ここで、別の問題が発生します。それは、データセンター内でサーバーが占めるスペース、つまりラック内のスペースの価格です。

これが事実であることに気づき、私たちはラックをどの程度効率的に使用しているかを計算することにしました。
私たちは、経済的に正当なサーバーの中から最も強力なサーバーの価格を計算し、ラックにそのようなサーバーを何台設置できるか、古いモデル「11 サーバー = XNUMX タスク」に基づいてそれらのサーバーで実行できるタスクの数、およびそのようなサーバーの量を計算しました。タスクでは機器を利用できます。 彼らは数を数えて涙を流しました。 ラックの使用効率は約 XNUMX% であることがわかりました。 結論は明らかです。データセンターの使用効率を高める必要があります。 解決策は明白であるように思えます。XNUMX つのサーバー上で複数のタスクを同時に実行する必要があります。 しかし、ここからが困難の始まりです。

一括構成は劇的に複雑になり、サーバーに XNUMX つのグループを割り当てることは不可能になりました。 結局のところ、現在では、異なるコマンドの複数のタスクを XNUMX つのサーバー上で起動できるようになりました。 さらに、異なるアプリケーションでは構成が競合する可能性があります。 診断もより複雑になります。サーバー上で CPU またはディスクの消費量が増加していることがわかっても、どのタスクが問題を引き起こしているのかわかりません。

しかし重要なことは、同じマシン上で実行されているタスク間には分離がないということです。 たとえば、ここにあるのは、同じサーバー上で別の計算アプリケーションが起動される前後のサーバー タスクの平均応答時間のグラフです。最初のアプリケーションとはまったく関係がなく、メイン タスクの応答時間が大幅に増加しています。

明らかに、タスクはコンテナーまたは仮想マシンで実行する必要があります。 ほぼすべてのタスクが XNUMX つの OS (Linux) で実行されるか、それに適応されるため、多くの異なるオペレーティング システムをサポートする必要はありません。 したがって、仮想化は必要ありませんが、オーバーヘッドが追加されるため、コンテナ化よりも効率が低くなります。

サーバー上でタスクを直接実行するためのコンテナの実装としては、Docker が有力な候補です。ファイル システム イメージは、構成の競合による問題をうまく解決します。 イメージを複数のレイヤーで構成できるという事実により、共通部分を個別の基本レイヤーに分離することで、イメージをインフラストラクチャに展開するために必要なデータ量を大幅に削減できます。 その後、基本的な (そして最もボリュームのある) レイヤーがインフラストラクチャ全体にわたってかなり迅速にキャッシュされ、多くの異なる種類のアプリケーションとバージョンを配信するために、小さなレイヤーのみを転送する必要があります。

さらに、Docker の既製のレジストリとイメージのタグ付けにより、コードをバージョン管理して運用環境に配信するための既製のプリミティブが提供されます。

Docker は、他の同様のテクノロジーと同様に、すぐに使用できる一定レベルのコンテナー分離を提供します。 たとえば、メモリの分離 - 各コンテナにはマシン メモリの使用制限が与えられ、それを超えると消費されなくなります。 CPU 使用率に基づいてコンテナを分離することもできます。 しかし、私たちにとって、標準的な断熱材では十分ではありませんでした。 ただし、それについては以下で詳しく説明します。

サーバー上でコンテナを直接実行することは問題の一部にすぎません。 もう XNUMX つの部分は、サーバー上でのコンテナーのホスティングに関連します。 どのコンテナをどのサーバーに配置できるかを理解する必要があります。 速度を落とさずにコンテナをできるだけ高密度にサーバーに配置する必要があるため、これはそれほど簡単な作業ではありません。 このような配置は、耐障害性の観点からも難しい場合があります。 多くの場合、同じサービスのレプリカをデータ センターの別のラックや別の部屋に配置して、ラックや部屋に障害が発生しても、すぐにすべてのサービス レプリカが失われないようにしたいと考えます。

サーバーが 8 台、コンテナーが 8 ～ 16 個ある場合、コンテナーを手動で配布することはできません。

さらに、開発者が管理者の助けを借りずに実稼働環境でサービスをホストできるように、リソース割り当ての独立性をさらに高めたいと考えていました。 同時に、小規模なサービスがデータ センターのリソースをすべて消費しないように制御を維持したいと考えていました。

明らかに、これを自動的に行う制御層が必要です。

そこで私たちは、すべての建築家が憧れる、シンプルでわかりやすい図、つまり XNUMX つの正方形にたどり着きました。

one-cloud masters は、クラウド オーケストレーションを担当するフェールオーバー クラスターです。 開発者は、サービスをホストするために必要なすべての情報を含むマニフェストをマスターに送信します。 これに基づいて、マスターは選択されたミニオン (コンテナーを実行するように設計されたマシン) にコマンドを与えます。 ミニオンにはエージェントがあり、エージェントはコマンドを受け取り、そのコマンドを Docker に発行し、Docker は対応するコンテナーを起動するように Linux カーネルを構成します。 エージェントはコマンドの実行に加えて、ミニオン マシンとその上で実行されているコンテナの両方の状態の変化についてマスターに継続的に報告します。

資源配分

次に、多くのミニオンに対するより複雑なリソース割り当ての問題を見てみましょう。

ワンクラウドのコンピューティング リソースは次のとおりです。

• 特定のタスクによって消費されるプロセッサ電力の量。
• タスクに使用可能なメモリの量。
• ネットワークトラフィック。 各ミニオンには帯域幅が制限された特定のネットワーク インターフェイスがあるため、ネットワーク上で送信されるデータ量を考慮せずにタスクを分散することは不可能です。
• ディスク。 さらに、当然のことですが、これらのタスク用のスペースには、ディスクの種類 (HDD または SSD) も割り当てられます。 ディスクは XNUMX 秒あたりの有限数のリクエスト (IOPS) に対応できます。 したがって、単一のディスクで処理できる以上の IOPS を生成するタスクの場合は、「スピンドル」、つまりタスク専用に予約する必要があるディスク デバイスも割り当てます。

次に、一部のサービス (ユーザー キャッシュなど) については、消費されたリソースを次の方法で記録できます。プロセッサ コア 400 個、メモリ 2,5 TB、双方向 50 Gbit/s トラフィック、6 スピンドル上にある 100 TB HDD スペース。 または、次のようなより一般的な形式でも構いません。

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

ユーザー キャッシュ サービス リソースは、運用インフラストラクチャで使用可能なすべてのリソースの一部のみを消費します。 したがって、オペレーターのエラーの有無にかかわらず、ユーザー キャッシュが割り当てられている以上のリソースを突然消費しないようにしたいと考えています。 つまり、リソースを制限する必要があります。 しかし、割り当てを何に結び付けることができるでしょうか?

コンポーネントの相互作用を非常に簡略化した図に戻って、さらに詳しく描き直してみましょう。次のようになります。

目を引くもの:

• Web フロントエンドと音楽は、同じアプリケーション サーバーの分離されたクラスターを使用します。
• これらのクラスターが属する論理層 (フロント、キャッシュ、データ ストレージ、管理層) を区別できます。
• フロントエンドは異種混合であり、異なる機能サブシステムで構成されています。
• キャッシュは、データをキャッシュするサブシステム全体に分散させることもできます。

もう一度絵を描き直してみましょう。

ああ！ はい、階層が表示されます。 これは、リソースをより大きな単位で分散できることを意味します。機能サブシステム (図の「音楽」など) に対応するこの階層のノードに責任のある開発者を割り当て、階層の同じレベルにクォータを割り当てます。 この階層により、サービスをより柔軟に編成して管理を容易にすることもできます。 たとえば、これは非常に大きなサーバーのグループであるため、すべての Web をいくつかの小さなグループに分割します (図では group1、group2 として示しています)。

余分な行を削除することで、画像の各ノードをより平坦な形式で書くことができます。 グループ1.web.フロント, api.music.front, ユーザーキャッシュ.キャッシュ.

これが「階層キュー」の概念に到達する方法です。 「group1.web.front」のような名前が付いています。 リソースとユーザー権限のクォータが割り当てられます。 DevOps の担当者にキューにサービスを送信する権限を与えます。そのような従業員はキュー内で何かを起動できます。OpsDev の担当者は管理者権限を持ち、キューを管理し、キューに人を割り当てることができるようになります。このキューで実行されているサービスは、キューのクォータ内で実行されます。 キューの計算クォータがすべてのサービスを一度に実行するのに十分でない場合、サービスは順番に実行され、キュー自体が形成されます。

サービスを詳しく見てみましょう。 サービスには完全修飾名があり、常にキューの名前が含まれます。 フロント Web サービスの名前は次のようになります。 ok-web.group1.web.front。 そして、アクセスするアプリケーションサーバーサービスは次のように呼ばれます ok-app.group1.web.front。 各サービスにはマニフェストがあり、特定のマシンに配置するために必要なすべての情報 (このタスクが消費するリソースの数、タスクに必要な構成、必要なレプリカの数、このサービスの障害を処理するためのプロパティ) を指定します。 サービスがマシンに直接配置されると、そのインスタンスが表示されます。 また、インスタンス番号とサービス名として、明確に名前が付けられます。 1.ok-web.group1.web.front、2.ok-web.group1.web.front、…

これは非常に便利です。実行中のコンテナの名前を見るだけで、すぐに多くのことを知ることができます。

次に、これらのインスタンスが実際に実行するタスク、つまりタスクを詳しく見てみましょう。

タスク分離クラス

OK のすべてのタスク (そしておそらくどこでも) はグループに分類できます。

• 待ち時間の短いタスク - prod。 このようなタスクやサービスでは、各リクエストがシステムによってどれだけ早く処理されるかという応答遅延 (レイテンシー) が非常に重要です。 タスクの例: Web フロント、キャッシュ、アプリケーション サーバー、OLTP ストレージなど。
• 計算問題 - バッチ。 ここで、各特定のリクエストの処理速度は重要ではありません。 彼らにとっては、このタスクが一定の (長い) 時間内にどれだけの計算を行うか (スループット) が重要です。 これらは、MapReduce、Hadoop、機械学習、統計のタスクになります。
• バックグラウンド タスク - アイドル状態。 このようなタスクでは、レイテンシもスループットもあまり重要ではありません。 これには、さまざまなテスト、移行、再計算、およびある形式から別の形式へのデータの変換が含まれます。 一方で、それらは計算されたものに似ていますが、他方では、どれだけ早く完了するかは私たちにとってあまり重要ではありません。

このようなタスクが中央プロセッサなどのリソースをどのように消費するかを見てみましょう。

遅延の短いタスク。 このようなタスクの CPU 消費パターンは次のようになります。

ユーザーからの処理リクエストを受信すると、タスクは利用可能なすべての CPU コアの使用を開始し、それを処理し、応答を返し、次のリクエストを待って停止します。 次のリクエストが到着しました - ここでも、そこにあるすべてのものを選択し、計算して、次のリクエストを待っています。

このようなタスクの最小レイテンシーを保証するには、タスクが消費するリソースを最大限に活用し、ミニオン (タスクを実行するマシン) 上に必要な数のコアを予約する必要があります。 この場合、問題の予約式は次のようになります。

alloc: cpu = 4 (max)

16 コアのミニオン マシンがある場合、そのようなタスクをちょうど XNUMX つ配置できます。 特に、このようなタスクの平均プロセッサ消費量が非常に低いことが多いことに注目します。タスクは時間のかなりの部分をリクエストを待って何もしないため、これは明らかです。

計算タスク。 それらのパターンは若干異なります。

このようなタスクの平均 CPU リソース消費量は非常に多くなります。 多くの場合、計算タスクを一定の時間内に完了させたいため、計算全体が許容可能な時間内に完了するように、必要な最小数のプロセッサを予約する必要があります。 その予約式は次のようになります。

alloc: cpu = [1,*)

「少なくとも XNUMX つの空きコアがあるミニオンに配置してください。そうすれば、コアがあればあるだけ、すべてを貪り食うでしょう。」

ここでの使用効率は、遅延が短いタスクよりもすでにはるかに優れています。 しかし、XNUMX 台のミニオン マシン上で両方のタイプのタスクを組み合わせ、そのリソースを外出先で分散すれば、その効果はさらに大きくなります。 遅延の短いタスクがプロセッサを必要とする場合、プロセッサはすぐにプロセッサを受け取り、リソースが不要になると、リソースは計算タスクに転送されます。つまり、次のようなものになります。

しかし、それを行う方法は？

まず、prod とその割り当てを見てみましょう: cpu = 4。XNUMX つのコアを予約する必要があります。 Docker run では、これは XNUMX つの方法で実行できます。

• オプションの使用 --cpuset=1-4つまり、マシン上の XNUMX つの特定のコアをタスクに割り当てます。
• 使用する --cpuquota=400_000 --cpuperiod=100_000、プロセッサ時間のクォータを割り当てます。つまり、タスクがリアルタイム 100 ミリ秒ごとに消費するプロセッサ時間が 400 ミリ秒以下であることを示します。 同じ XNUMX つのコアが得られます。

しかし、これらの方法のうちどれが適切でしょうか?

cpuset は非常に魅力的に見えます。 このタスクには XNUMX つの専用コアがあり、プロセッサ キャッシュが可能な限り効率的に動作することを意味します。 これには欠点もあります。OS ではなく、マシンのアンロードされたコア全体に計算を分散するタスクを引き受ける必要があり、特にそのようなマシンにバッチ タスクを配置しようとする場合、これはかなり簡単なタスクではありません。機械。 テストの結果、ここではクォータ付きのオプションの方が適していることがわかりました。この方法では、オペレーティング システムが現時点でタスクを実行するコアをより自由に選択できるようになり、プロセッサ時間がより効率的に分散されます。

最小コア数に基づいて Docker で予約する方法を考えてみましょう。 最大値を制限する必要はなく、最小値を保証するだけで十分であるため、バッチ タスクのクォータは適用されなくなりました。 そして、ここではオプションがうまく適合します docker run --cpushares.

バッチで少なくとも XNUMX つのコアの保証が必要な場合は、次のことを示すことに同意しました。 --cpushares=1024、少なくとも XNUMX つのコアがある場合は、 --cpushares=2048。 CPU シェアは、十分な量がある限り、プロセッサ時間の配分にまったく干渉しません。 したがって、prod が現在その 1024 つのコアすべてを使用していない場合、バッチ タスクを制限するものは何もないため、追加のプロセッサ時間を使用することができます。 ただし、プロセッサーが不足している状況で、prod が 2048 つのコアをすべて消費してクォータに達した場合、残りのプロセッサー時間は cpushare に比例して分割されます。つまり、XNUMX つの空きコアがある状況では、XNUMX つは CPU シェアに比例して分割されます。 XNUMX CPU シェアのタスクに割り当てられ、残りの XNUMX つは XNUMX CPU シェアのタスクに割り当てられます。

しかし、クォータとシェアを使用するだけでは十分ではありません。 プロセッサ時間を割り当てる際には、遅延の短いタスクがバッチ タスクよりも優先されるようにする必要があります。 このような優先順位付けがないと、本番環境でバッチ タスクが必要になった瞬間に、バッチ タスクがすべてのプロセッサ時間を占有することになります。 Docker の実行にはコンテナーの優先順位付けオプションはありませんが、Linux CPU スケジューラー ポリシーは便利です。 それらについて詳しく読むことができます ここでそして、この記事の枠組みの中で、それらを簡単に説明します。

• SCHED_OTHER
  デフォルトでは、Linux マシン上のすべての通常のユーザー プロセスが受信します。
• SCHED_BATCH
  リソースを大量に消費するプロセス向けに設計されています。 タスクをプロセッサに配置すると、いわゆるアクティベーション ペナルティが導入されます。そのようなタスクが現在 SCHED_OTHER を持つタスクによって使用されている場合、そのタスクはプロセッサ リソースを受け取る可能性が低くなります。
• SCHED_IDLE
  優先度が非常に低く、nice -19 よりもさらに低いバックグラウンド プロセス。 私たちはオープンソースライブラリを使用しています ワンニオを呼び出してコンテナを起動するときに必要なポリシーを設定するため

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ただし、Java でプログラムを作成していない場合でも、chrt コマンドを使用して同じことができます。

chrt -i 0 $pid

わかりやすくするために、すべての分離レベルを XNUMX つの表にまとめてみましょう。

絶縁クラス
割り当ての例
Docker 実行オプション
sched_setscheduler チャート*

突く
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

バッチ
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

アイドル
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*コンテナ内から chrt を実行している場合は、sys_nice 機能が必要になる場合があります。これは、コンテナの起動時にデフォルトで Docker がこの機能を削除するためです。

ただし、タスクはプロセッサだけでなくトラフィックも消費するため、プロセッサ リソースの不適切な割り当てよりもネットワーク タスクの遅延にさらに大きな影響を与えます。 したがって、当然のことながら、トラフィックについてもまったく同じ画像を取得したいと考えます。 つまり、本番タスクがいくつかのパケットをネットワークに送信するとき、最大速度を制限します（式 alloc: lan=[*,500mbps) )、prod でこれを行うことができます。 また、バッチの場合は、最小スループットのみを保証しますが、最大スループットは制限しません（式 alloc: lan=[10Mbps,*) ) この場合、本番トラフィックはバッチ タスクよりも優先される必要があります。
ここで、Docker には使用できるプリミティブがありません。 しかし、それは私たちの助けになります Linux トラフィック制御。 私たちは規律の助けを借りて望ましい結果を達成することができました 階層的公正サービス曲線。 これを利用して、優先度の高い本番と優先度の低いバッチ/アイドルという XNUMX つのクラスのトラフィックを区別します。 その結果、送信トラフィックの構成は次のようになります。

ここで、1:0 は hsfc 規律の「ルート qdisc」です。 1:1 - 総帯域幅制限が 8 Gbit/s の hsfc 子クラス。その下にすべてのコンテナの子クラスが配置されます。 1:2 - hsfc 子クラスは、以下で説明する「動的」制限を持つすべてのバッチ タスクとアイドル タスクに共通です。 残りの hsfc 子クラスは、マニフェストに対応する制限 (450 および 400 Mbit/s) を持つ、現在実行中の本番コンテナ用の専用クラスです。 各 hsfc クラスには、トラフィック バースト時のパケット損失を避けるために、Linux カーネルのバージョンに応じて qdisc キュー fq または fq_codel が割り当てられます。

通常、TC 規律は送信トラフィックのみを優先する役割を果たします。 しかし、受信トラフィックにも優先順位を付けたいと考えています。結局のところ、一部のバッチ タスクは、たとえば、map&reduce の入力データの大きなバッチを受信するなど、受信チャネル全体を簡単に選択できます。 このために、モジュールを使用します ifbこれにより、ネットワーク インターフェイスごとに ifbX 仮想インターフェイスが作成され、そのインターフェイスからの受信トラフィックが ifbX 上の送信トラフィックにリダイレクトされます。 さらに、ifbX の場合、発信トラフィックの制御にはすべて同じ規律が機能し、hsfc 設定は非常に似ています。

実験中に、ミニオン マシン上の非優先バッチ/アイドル トラフィックの 1:2 クラスが特定の空きレーン以下に制限されている場合、hsfc が最良の結果を示すことがわかりました。 そうしないと、非優先トラフィックが本番タスクのレイテンシーに大きな影響を与えます。 miniond は、特定のミニオンのすべての prod タスクの平均トラフィック消費量を測定して、現在の空き帯域幅の量を毎秒決定します。 そしてそれをネットワークインターフェイスの帯域幅から差し引きます わずかなマージンを持って、つまり

帯域は、受信トラフィックと送信トラフィックに対して個別に定義されます。 そして、新しい値に従って、miniond は非優先クラスの制限を 1:2 に再構成します。

したがって、prod、batch、idle の XNUMX つの分離クラスをすべて実装しました。 これらのクラスは、タスクのパフォーマンス特性に大きな影響を与えます。 したがって、階層キューの名前を見ると、何を扱っているのかがすぐにわかるように、この属性を階層の最上位に配置することにしました。

私たちの友達全員 ウェブ и 音楽 フロントは prod の下の階層に配置されます。 たとえば、バッチの下にサービスを配置しましょう 音楽カタログ、Odnoklassniki にアップロードされた mp3 ファイルのセットからトラックのカタログを定期的にコンパイルします。 アイドル状態のサービスの例は次のとおりです。 ミュージックトランスフォーマー、音楽の音量レベルを正規化します。

余分な行を再度削除すると、完全なサービス名の末尾にタスク分離クラスを追加することで、サービス名をより平坦に書くことができます。 web.front.prod, カタログ.音楽.バッチ, トランスフォーマーミュージックアイドル.

そして今、サービスの名前を見ると、それがどのような機能を実行するかだけでなく、その重要性などを意味する分離クラスも理解できます。

すべてが素晴らしいですが、苦い真実が XNUMX つあります。 XNUMX 台のマシンで実行されているタスクを完全に分離することは不可能です。

達成できたこと: バッチが集中的に消費する場合 のみ CPU リソースがあれば、組み込みの Linux CPU スケジューラが非常に適切に機能し、本番タスクには実質的に影響を与えません。 しかし、このバッチ タスクがメモリを積極的に処理し始めると、相互の影響がすでに現れています。 これは、prod タスクがプロセッサのメモリ キャッシュから「洗い流される」ために発生します。その結果、キャッシュ ミスが増加し、プロセッサによる prod タスクの処理が遅くなります。 このようなバッチ タスクにより、一般的な本番コンテナのレイテンシが 10% 増加する可能性があります。

最近のネットワーク カードには内部パケット キューがあるため、トラフィックを分離することはさらに困難です。 バッチ タスクからのパケットが最初に到着した場合、それが最初にケーブル経由で送信されることになり、それについては何もできません。

さらに、これまでのところ、TCP トラフィックの優先順位付けの問題しか解決できていません。hsfc アプローチは UDP では機能しません。 また、TCP トラフィックの場合でも、バッチ タスクが大量のトラフィックを生成すると、本番タスクの遅延が約 10% 増加します。

耐障害性

ワンクラウドを開発する際の目標の XNUMX つは、Odnoklassniki の耐障害性を向上させることでした。 そこで次に、起こり得る故障や事故のシナリオをより詳しく考えてみたいと思います。 コンテナーの障害という単純なシナリオから始めましょう。

コンテナ自体はさまざまな方法で失敗する可能性があります。 これは、マニフェスト内の何らかの実験、バグ、またはエラーである可能性があり、これが原因で、prod タスクがマニフェストに示されているよりも多くのリソースを消費し始めます。 ある開発者が XNUMX つの複雑なアルゴリズムを実装し、何度もやり直し、考えすぎて混乱し、最終的に問題が非常に単純ではない形でループしてしまうというケースがありました。 そして、prod タスクは同じミニオン上の他のすべてのタスクよりも高い優先順位を持っているため、利用可能なすべてのプロセッサ リソースを消費し始めました。 この状況では、分離、つまり CPU 時間の割り当てによって窮地を救われました。 タスクにクォータが割り当てられている場合、タスクはそれ以上のクォータを消費しません。 したがって、同じマシン上で実行されるバッチおよびその他の本番タスクは何も認識しませんでした。

XNUMX 番目に考えられる問題は、コンテナの落下です。 そして、ここで再起動ポリシーが私たちを救ってくれます。誰もがそれを知っていますが、Docker 自体は素晴らしい仕事をします。 ほとんどすべての本番タスクには、常に再起動するポリシーがあります。 バッチ タスクや本番コンテナのデバッグに on_failure を使用することがあります。

ミニオン全体が利用できない場合はどうすればよいでしょうか?

当然、コンテナを別のマシンで実行します。 ここで興味深いのは、コンテナに割り当てられた IP アドレスがどうなるかということです。

これらのコンテナが実行されるミニオン マシンと同じ IP アドレスをコンテナに割り当てることができます。 その後、コンテナが別のマシンで起動されると、その IP アドレスが変更され、すべてのクライアントはコンテナが移動したことを理解する必要があり、別のアドレスに移動する必要があるため、別の Service Discovery サービスが必要になります。

サービスディスカバリーは便利です。 市場には、サービス レジストリを編成するための、さまざまな程度の耐障害性を備えた多くのソリューションが存在します。 多くの場合、このようなソリューションではロード バランサー ロジックが実装され、KV ストレージなどの形式で追加の構成が保存されます。
ただし、別のレジストリを実装する必要性は避けたいと考えています。これは、本番環境のすべてのサービスで使用される重要なシステムを導入することを意味するためです。 これは、これが潜在的な障害点であることを意味し、非常に耐障害性の高いソリューションを選択または開発する必要がありますが、これは明らかに非常に困難で、時間と費用がかかります。

そして、もう XNUMX つの大きな欠点があります。古いインフラストラクチャを新しいインフラストラクチャと連携させるには、ある種の Service Discovery システムを使用するようにすべてのタスクを完全に書き直す必要があります。 多くの作業があり、OS カーネル レベルで動作する、またはハードウェアと直接動作する低レベルのデバイスに関しては、場所によってはほとんど不可能です。 次のような確立されたソリューション パターンを使用してこの機能を実装します。 サイドカー これは、ある場所では追加の負荷がかかることを意味し、別の場所では操作が複雑になり、追加の障害シナリオが発生することを意味します。 物事を複雑にしたくなかったので、Service Discovery の使用をオプションにすることにしました。

XNUMX つのクラウドでは、IP はコンテナに従います。つまり、各タスク インスタンスは独自の IP アドレスを持ちます。 このアドレスは「静的」です。サービスが最初にクラウドに送信されるときに各インスタンスに割り当てられます。 サービスの存続期間中に異なる数のインスタンスがあった場合、最終的には最大インスタンスと同じ数の IP アドレスが割り当てられます。

その後、これらのアドレスは変更されません。これらのアドレスは一度割り当てられると、運用環境でのサービスの存続期間中ずっと存在し続けます。 IP アドレスはネットワーク上のコンテナに従います。 コンテナが別のミニオンに転送された場合、アドレスはそれに続きます。

したがって、サービス名の IP アドレスのリストへのマッピングが変更されることはほとんどありません。 この記事の冒頭で説明したサービス インスタンスの名前をもう一度見てみましょう (1.ok-web.group1.web.front.prod、2.ok-web.group1.web.front.prod、…)、DNS で使用される FQDN に似ていることがわかります。 そうです、サービス インスタンスの名前をその IP アドレスにマッピングするには、DNS プロトコルを使用します。 さらに、この DNS は、実行中と停止の両方のすべてのコンテナーのすべての予約済み IP アドレスを返します (XNUMX つのレプリカが使用されており、そこに XNUMX つのアドレスが予約されているとします。XNUMX つすべてが返されます)。 この情報を受け取ったクライアントは、XNUMX つのレプリカすべてとの接続を確立しようとし、動作しているレプリカを判断します。 可用性を判断するためのこのオプションは、はるかに信頼性が高く、DNS やサービス検出が関与しないため、情報の関連性とこれらのシステムのフォールト トレランスを確保する際に解決するのは難しい問題がありません。 さらに、ポータル全体の運用が依存する重要なサービスでは、DNS をまったく使用できず、構成に IP アドレスを入力するだけです。

このような IP 転送をコンテナの背後に実装することは簡単ではありません。次の例でそれがどのように機能するかを見ていきます。

ワンクラウド マスターがミニオン M1 に実行するコマンドを与えたとします。 1.ok-web.group1.web.front.prod アドレスは 1.1.1.1 です。 ミニオンで動作します バード、このアドレスを特別なサーバーにアドバタイズします ルートリフレクター。 後者はネットワーク ハードウェアとの BGP セッションを持ち、M1.1.1.1 上のアドレス 1 のルートが変換されます。 M1 は、Linux を使用してコンテナ内でパケットをルーティングします。 これは XNUMX クラウド インフラストラクチャの非常に重要な部分であるため、ルート リフレクタ サーバーが XNUMX つあります。これらがなければ、XNUMX クラウドのネットワークは機能しません。 XNUMX つすべてが同時に故障する可能性を減らすために、これらを異なるラックに配置し、可能であればデータ センターの異なる部屋に配置します。

次に、1 クラウド マスターと M1 ミニオンの間の接続が失われたと仮定します。 2 クラウド マスターは、MXNUMX が完全に失敗したという想定に基づいて動作するようになります。 つまり、MXNUMX ミニオンに起動のコマンドを与えます。 web.group1.web.front.prod 同じアドレス 1.1.1.1 です。 現在、1.1.1.1 のネットワーク上には、M1 と M2 の 1 つの競合するルートがあります。 このような競合を解決するために、BGP アナウンスで指定されている Multi Exit Discriminator を使用します。 広告する経路の重みを表す数値です。 競合する経路のうち、MED 値が小さい経路が選択されます。 ワンクラウド マスターは、コンテナー IP アドレスの不可欠な部分として MED をサポートします。 初めて、アドレスは十分に大きな MED = 000 で書き込まれます。このような緊急コンテナ転送の状況では、マスターは MED を削減し、M000 はすでにアドレス 2 を MED = でアドバタイズするコマンドを受信します。 1.1.1.1。この場合、接続がない場合、M999 で実行されているインスタンスはそのまま残り、マスターとの接続が回復するまで、彼の今後の運命にはほとんど興味がありません。マスターとの接続が回復すると、古いテイクのように停止されます。

障害

すべてのデータセンター管理システムは、軽微な障害を常に適切に処理します。 コンテナのオーバーフローは、ほぼどこでもよくあることです。

データセンターの XNUMX つまたは複数の部屋での停電などの緊急事態にどのように対処するかを見てみましょう。

事故はデータセンター管理システムにとって何を意味しますか? まず第一に、これは多くのマシンの一度限りの大規模な障害であり、制御システムは同時に多くのコンテナを移行する必要があります。 しかし、災害が非常に大規模な場合、データセンターのリソース容量が負荷の 100% を下回るために、すべてのタスクを他のミニオンに再割り当てできない場合があります。

多くの場合、事故には制御層の障害が伴います。 これは、機器の故障によって発生する可能性がありますが、より多くの場合、事故がテストされていないという事実や、負荷の増加により制御層自体が低下するという事実が原因です。

これらすべてについて何ができるでしょうか?

大量移行とは、インフラストラクチャ内で多数のアクティビティ、移行、および展開が発生することを意味します。 各移行では、ミニオンへのコンテナ イメージの配信と解凍、コンテナの起動と初期化などに時間がかかる場合があります。そのため、より重要なタスクを、それほど重要でないタスクよりも前に起動することが望ましいです。

私たちがよく知っているサービスの階層をもう一度見て、どのタスクを最初に実行するかを決定してみましょう。

もちろん、これらはユーザー要求の処理に直接関与するプロセス、つまり prod です。 これを次のように示します。 配置の優先順位 — キューに割り当てることができる番号。 キューの優先順位が高い場合、そのサービスが最初に配置されます。

prod では、より高い優先度 0 を割り当てます。 バッチでは-少し低く、100; アイドル時 - さらに低い 200。優先順位は階層的に適用されます。 階層の下位のすべてのタスクには、対応する優先度が設定されます。 フロントエンドよりも前に製品内のキャッシュを起動したい場合は、キャッシュ = 0、フロント サブキュー = 1 に優先順位を割り当てます。たとえば、メイン ポータルを最初にフロントエンドから起動し、ミュージック フロントのみを起動したい場合次に、後者に低い優先順位 (10) を割り当てることができます。

次の問題はリソースの不足です。 そのため、大量の機器、つまりデータセンターのホール全体が故障し、非常に多くのサービスを再起動したため、現在では全員に十分なリソースがありません。 主要な重要なサービスを実行し続けるために、どのタスクを犠牲にするかを決定する必要があります。

配置の優先順位とは異なり、すべてのバッチ タスクを無差別に犠牲にすることはできません。それらの一部はポータルの運用にとって重要です。 したがって、個別に強調表示しました プリエンプションの優先順位 タスク。 配置されると、空きミニオンがなくなった場合、優先度の高いタスクは優先度の低いタスクをプリエンプト、つまり停止することができます。 この場合、優先度の低いタスクはおそらく配置されないままになるでしょう。つまり、十分な空きリソースを備えた適切なミニオンはもう存在しません。

この階層では、アイドルの優先順位を 200 に指定することで、本番タスクとバッチ タスクがアイドル タスクをプリエンプトまたは停止しますが、相互にはプリエンプション優先順位を指定することは非常に簡単です。配置優先順位の場合と同様に、より複雑なルールを記述するために階層を使用できます。 たとえば、メイン Web ポータルに十分なリソースがない場合は音楽機能を犠牲にし、対応するノードの優先順位を 10 と低く設定してみましょう。

直流事故全体

データセンター全体に障害が発生する可能性があるのはなぜですか? 要素。 良い投稿でした ハリケーンはデータセンターの業務に影響を与えた。 それらの要素は、かつてマニホールド内の光学系を焼き付けたホームレスの人々であると考えられ、データセンターは他のサイトとの接続を完全に失いました。 障害の原因は人的要因である場合もあります。オペレーターは、データセンター全体が崩壊するようなコマンドを発行します。 これは大きなバグが原因で発生する可能性があります。 一般に、データセンターが崩壊することは珍しいことではありません。 私たちには数か月に一度このようなことが起こります。

これは、誰も #alive をツイートできないようにするために行っていることです。

最初の戦略は孤立です。 各 XNUMX クラウド インスタンスは分離されており、XNUMX つのデータ センターでのみマシンを管理できます。 つまり、バグやオペレーターの誤ったコマンドによるクラウドの損失は、データセンターが XNUMX つだけ失われることになります。 私たちはこれに対する準備ができています。私たちは、アプリケーションとデータのレプリカをすべてのデータセンターに配置する冗長性ポリシーを持っています。 当社はフォールトトレラントなデータベースを使用し、定期的に障害をテストします。
現在、当社には XNUMX つのデータセンターがあります。これは、XNUMX つのクラウドの XNUMX つの個別の完全に分離されたインスタンスを意味します。

このアプローチは、物理的な障害から保護するだけでなく、オペレーターのエラーからも保護できます。

人的要因に関して他に何ができるでしょうか? オペレーターがクラウドに奇妙なコマンド、または潜在的に危険なコマンドを与えると、自分がどれだけうまく考えたかを確認するために、突然小さな問題を解決するように求められることがあります。 たとえば、これが多数のレプリカの何らかの一括停止である場合、または単なる奇妙なコマンドである場合、新しいマニフェストのバージョン番号だけでなく、レプリカの数を減らすか、イメージの名前を変更します。

結果

ワンクラウドの特徴:

• サービスとコンテナの階層的かつ視覚的な命名スキームこれにより、タスクが何であるか、何に関連しているか、どのように機能するか、誰がその責任者であるかをすぐに知ることができます。
• 私たちは私たちの プロダクトとバッチを組み合わせる手法マシン共有の効率を向上させるためにミニオンでタスクを実行します。 cpuset の代わりに、CPU クォータ、シェア、CPU スケジューラ ポリシー、および Linux QoS を使用します。
• 同じマシン上で実行されているコンテナを完全に分離することはできませんが、相互の影響は 20% 以内にとどまります。
• サービスを階層に編成すると、次を使用した自動災害復旧に役立ちます。 配置とプリエンプションの優先順位.

よくある質問

なぜ既製のソリューションを採用しなかったのでしょうか?

• タスク分離のクラスが異なると、ミニオンに配置するときに異なるロジックが必要になります。 リソースを予約するだけで本番タスクを配置できる場合は、ミニオン マシン上のリソースの実際の使用状況を追跡しながら、バッチ タスクとアイドル タスクを配置する必要があります。
• 次のようなタスクによって消費されるリソースを考慮する必要があります。
  • ネットワーク帯域幅。
  • ディスクの種類と「スピンドル」。
• 緊急対応中のサービスの優先順位、リソースに対するコマンドの権限と割り当てを示す必要がありますが、これはワンクラウドの階層キューを使用して解決されます。
• 事故やインシデントへの対応時間を短縮するために、コンテナに人間が名前を付ける必要性
• Service Discovery を XNUMX 回限りで広範に実装することは不可能です。 ハードウェア ホストでホストされているタスクと長期間共存する必要があります。これは、コンテナに続く「静的」IP アドレスによって解決され、その結果、大規模なネットワーク インフラストラクチャとの独自の統合が必要になります。

これらすべての機能を使用するには、当社に合わせて既存のソリューションを大幅に変更する必要がありますが、作業量を評価した結果、ほぼ同じ人件費で独自のソリューションを開発できることがわかりました。 ただし、ソリューションの操作と開発ははるかに簡単になります。必要のない機能をサポートする不必要な抽象化が含まれていません。

最後まで読んでくださった皆様、忍耐と注目をありがとうございました!

出所： habr.com