余分な要素、またはサーバー間のバランスの取り方

こんにちは、Habr！ 少し前に、人々は、負荷の増加に応じてサーバーの電力を増やすことは単に不可能であることを認識していました。 その後、「クラスター」という言葉を学びました。 しかし、この言葉がどれほど美しいものであっても、異なるサーバーを技術的に組み合わせて単一の全体、つまり同じクラスターにする必要があります。 都市や村では、以前の作品でノードに到達しました。 そして今日の私の話は、システムインテグレーターがクラスターメンバー間で負荷をどのように分担し、どのようにそれを行ったかについてです。







出版物の内部では、 毎月のivi +サブスクリプションの 3つの証明書の形でボーナスも受け取ります 。

みんなでやる

クラスターの課題は何ですか？



1.大量のトラフィック

2.高い信頼性

03d63a0996fb

これを達成する方法は？ サーバー間で負荷を共有する最も簡単な方法は、負荷を共有しないことです。 むしろ、サーバーの完全なリストを提供しましょう-クライアント自身に理解してもらいましょう。 どうやって？ はい、指定された名前のサーバーのすべてのIPアドレスをDNSに登録するだけです。 ラウンドロビンDNSの古くて有名なバランス調整。 そして一般に、ホストを追加する必要があるまではうまく機能します-DNSキャッシュの不活性についてはすでに書いています。 DNSバランシングは次のようになります。









また、サーバーをクラスターから削除する必要がある場合（壊れた場合）、カヤックがあります。 kayukが私たちを踏まないようにするには、壊れたサーバーのIPをどこかですぐに切断する必要があります。 どこへ？ さて、隣人と言ってみましょう。 さて、これをどのように自動化できますか？ このために、独自の長所と短所を持つVRRPやCARPのような多数のプロトコルが発明されました。



通常、最初に置かれるのはルーター上のARPキャッシュです。これは、IPアドレスが別のMACに移動したことを理解したくないためです。 ただし、最新の実装では、新しいMACからルーターを「ping」する（この方法でキャッシュを更新する）か、動作中に変更されない仮想MACを使用します。



2つ目の問題は、サーバーリソースです。 ホットスタンバイで2台のうち1台のサーバーを維持しませんか？ サーバーは動作するはずです！ したがって、VRRPを介して各サーバーで2つのアドレスを予約します。1つはプライマリ、もう1つはバックアップです。 ペアのサーバーの1つが故障した場合、2番目のサーバーがすべての負荷を引き受けます...多分...故障した場合。 そして、このような「ペアリング」が主な欠点になります。サーバー電源の二重供給を維持することが常に可能または適切ではないためです。



また、各サーバーが独自のグローバルにルーティング可能なIPアドレスを必要としていることに気付くことはできません。 困難な時期には、これは大きな問題になる可能性があります。



一般的に、私はこのバランスと冗長性の方法が好きではありませんが、多くのタスクとトラフィック量には適しています。 シンプル 追加の機器は必要ありません-すべてがサーバーソフトウェアによって行われます。

ボールの上

単純なソリューションの列挙を続けますか、それとも複数のサーバーで同じIPアドレスをハングアップする必要がありますか？ さて、IPv6では、1つのドメインでエニーキャストを作成することができます（そして、その中のホストに対してのみバランシングが行われますが、外部ホストに対してはまったく行われません）が、IPv4ではそのようなことは単にARP競合（よりよく知られているアドレス競合）を作成します。 しかし、これは「額」の場合です。



また、コード名「共有アドレス」（共有アドレス）の下で小さな工夫をすれば、これは可能です。 トリックの要点は、最初に着信一意性をブロードキャストに変換し（必要に応じて、マルチキャストを許可する）、その後、このクライアントからのパケットに応答するのは1つのサーバーのみです。 変換はどのように実行されますか？ 非常に簡単：ARP要求に応答するすべてのクラスターサーバーは、ネットワーク上に存在しないかマルチキャストのいずれかの同じMACを返します。 その後、ネットワーク自体が着信パケットにクラスターのすべてのメンバーを掛けます。 そして、サーバーは、誰が責任を負うかについてどのように同意しますか？ 簡単にするために、これを言ってみましょう：srcIPをクラスター内のサーバーの数で割った残り。 次は技術の問題です。









共有アドレスバランシング



この手法は、さまざまなモジュールとさまざまなプロトコルによって実装されます。 FreeBSDでは、この機能は実装されてCARP 。 過去のLinuxでは、かつてClusterIPを使用していました 。 今、明らかに、それは開発されていません。 しかし、私は他の実装があると確信しています。 Windowsの場合、そのようなことは組み込みのクラスタリングツールにあります。 一般的に、選択肢があります。



このようなバランスの利点は、依然として純粋にサーバーベースの実装です。ネットワーク側からの特別な構成は必要ありません。 パブリックアドレスは1つだけです。 クラスター内の単一サーバーの追加または切断は迅速です。



欠点は、第1に、アプリケーションレベルで追加の検証が必要であり、第2に（そして「主に」）着信帯域に制限があることです。着信トラフィックの量は、サーバーの物理接続の帯域を超えることができません。 そしてこれは明らかです。結局のところ、着信トラフィックはすべてのサーバーに同時に送られます。



したがって、一般的に、これは少しの着信トラフィックがある場合にトラフィックのバランスをとる良い方法ですが、賢明に使用する必要があります。 そして、ここで私は控えめに言って、今はこの方法を使用しません。 着信トラフィックの問題のため。

インテグレーターと話さない

何らかの理由で、サーバー間のバランスをとるタスクは典型的であるように思えます。 また、典型的な問題については、標準的な解決策があるはずです。 そして、典型的なソリューションをうまく販売しているのは誰ですか？ インテグレーター！ そして私たちは尋ねました...



言うまでもなく、さまざまな機器のワゴンからソリューションを提供されましたか？ Cisco ACEからあらゆる種類のF5 BigIP LTMまで 。 高価な しかし、それは良いですか？ さて、もう1つの優れた無料のhaproxyソフトウェアL7バランサーがあります。



これらのことの意味は何ですか？ ポイントは、アプリケーションレベル（レイヤ7）でバランシングを行うことです。実際、このようなバランサーは完全なプロキシです。クライアントとサーバーとの接続を確立します。 理論的には、クライアントを特定のサーバー（サーバーアフィニティ）に固定し、要求されたコンテンツ（ ivi.ruなどのリソースにとって非常に有用なもの）に応じてバックエンドを選択することもできるため、これは良いことです。 そして、特定の設定で-リクエストをURLでフィルタリングし、さまざまな種類の攻撃から保護します。 主な利点は、このようなバランサーがクラスター内の各ノードの実行可能性を個別に決定できることです。









バランサーは何らかの形でネットワークに接続されています



私の過去の経験は「バランサーなしでは何もできない」と叫びました。 私たちは数えました...そして、ぞっとしました。



私たちが提供した最も生産的なバランサーは、10 Gbit / sの帯域幅を備えていました。 私たちの基準では、面白くありません（重いコンテンツを持つサーバーは2 * 10ギガビット/秒で接続します）。 したがって、適切なレーンを確保するには、予約を考慮して、ラック全体をこのようなバランサーで満たす必要があります。 この図をご覧ください。









これは、バランサーの物理的な接続です。



もちろん、部分的なプロキシモード（ハー​​フプロキシ）もあります。トラフィックの半分のみがバランサーを通過する場合です。クライアントからサーバーへ、そしてサーバーから戻る-それは直接行きます。 ただし、このモードではL7機能が無効になり、バランサーがL3-L4になり、その値が大幅に減少します。 そして、次の2つの問題が順番に発生します。まず、十分なネットワーク電力を確保する必要があります（まず、ポートごと、次に信頼性ごと）。 次に問題が発生します：バランサー間で負荷を分散する方法 モスクワでは、理論的には、おそらくバランスを取るための機器を備えたラックを設置することができます。 しかし、ノードが最小限の領域（サーバーとツィスカ）では、いくつかのバランサーを追加することは、とんでもないことではありません。 さらに、チェーンが長いほど、信頼性は低くなります。 必要ですか？

ECMPまたはそれ以上

ソリューションはほとんど偶然にグーグルで検索されました。 最新のルーター自体でトラフィックのバランスを取ることができます。 考えてみると、これは合理的です。結局のところ、同じサブネットに同じ品質で異なるチャネルを介してアクセスできます。 この機能はECMP -Equal Cost Multiple Pathsと呼ばれます。 （一般的な意味で）メトリックで同一のルートを見ると、ルーターは単にこれらのルート間でパケットを分割します。



OK、アイデアは面白いですが、うまくいくでしょうか？ ルーターから複数のサーバーの側面への静的ルートを登録して、テストの起動を実行しました。 コンセプトは実行可能であることが判明しましたが、追加の作業が必要でした。



まず 、同じTCPセッションに属するすべてのIPパケットが同じサーバーに到達するようにする必要があります。 実際、そうでない場合、TCPセッションは実行されません。 これはいわゆる「フローごと」（または「宛先ごと」​​）モードであり、Ciscoルータではデフォルトでオンになっているようです。



第二に 、静的ルートは適切ではありません-破損したサーバーをクラスターから自動的に削除する必要があるためです。 つまり 何らかの動的ルーティングプロトコルを使用する必要があります。 一貫性を保つために、 BGPを選択しました。 ソフトウェアルーターがサーバーにインストールされ（現在はquaggaですが、近い将来、 BIRDに切り替えます）、ルーターの「サーバー」ネットワークを通知します。 サーバーがアナウンスの送信を停止するとすぐに、ルーターはトラフィックの配信を停止します。 したがって、ルーターでのバランスをとるために、 maximum-paths ibgp



値はクラスター内のサーバーの数と同じ値にmaximum-paths ibgp



ます（いくつかの予約あり）。

  router bgp 57629 address-family ipv4 maximum-paths ibgp 24
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、BGP自体はサーバーのネットワーク可用性のみを保証し、アプリケーションは保証しません。 アプリケーションソフトウェアの機能を確認するために、一連のチェックを実行するスクリプトがサーバー上で起動され、何か問題が発生した場合は単にBGPを消滅させます。 ルーターのビジネスは、このサーバーへのパケット送信を停止することです。



第三に 、サーバー間での要求の分散の不均一性が認められました。 小さく、クラスタリングソフトウェアによって補償されていますが、均一性が必要でした。 デフォルトでは、ルーターはパケットの送信者と受信者のアドレスに基づいてパケットのバランスをとることが判明しました。つまり、L3バランシングです。 受信者（サーバー）アドレスが常に同じであるという事実に基づいて、これは送信元アドレスの不均一性を示しています。 インターネットの大規模なNAT化を考えると、これは驚くことではありません。 解決策はシンプルであることが判明しました。次のようなコマンドを使用して、ルーターに受信ポートと送信元ポート（L4-balancing）を考慮させることです。

 platform ip cef load-sharing full
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 ip cef load-sharing algorithm include-ports source destination
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

iOSに依存します。 主なことは、そのようなコマンドがないことです。

 ip load-sharing per-packet
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最終的な図は次のようになります。









なじみのあることに気づきましたか？ まあ、それは実際には地域間だけでなく、1つのノード内のエニーキャストですか？ これで終わりです！



L3-L4バランシングの利点は効率です。ルーターは、それなしでは何もないはずです。 信頼性も最高です-ルーターが突然故障した場合、それ以上の問題はありません。 追加の機器は購入しません-これは良いことです。 パブリックアドレスも使用されません-同じIPが一度に複数のサーバーによって提供されます。



残念ながら、欠点もあります。



1.サーバーに追加のソフトウェアをインストール、構成などする必要があります。 確かに、このソフトウェアはかなり控えめであり、サーバーリソースを消費しません。 だから-寛容。



2. 1つのサーバーの過渡現象（クラスターへの包含または除外）は、クラスター全体に影響します。 結局のところ、ルーターはサーバーについて何も知らない-ルーターとチャネルを扱っていると考えている。 したがって、すべての接続は、使用可能なすべてのチャネルに分散されます。 サーバーアフィニティなし。 その結果、サーバーの電源を切ると、残りのすべてのサーバー間ですべての接続がシャッフルされます。 そして、すべてのアクティブなTCPセッションが中断します（厳密に言えば、すべてではなく、一部が同じサーバーに戻る可能性があります）。 これは悪いことですが、そのような状況（プレーヤーは接続が切断されるとコンテンツを再要求します）および耳を失った（これについては後で説明します）から保護されているので、生きることができます。



3.ルータがトラフィックを共有できる等しいルートの数には制限があります。Cisco3750Xおよび4500-Xでは8、6500 + Sup2Tでは32です（ただしジョークが1つあります）。 一般に、これで十分です。さらに、この制限を緩和できるトリックもあります。



4.このスキームでは、すべてのサーバーの負荷が均等に分散されるため、すべてのサーバーで均一性が要求されます。 また、より近代的で強力なサーバーをクラスターに追加した場合、その負荷は近隣サーバーの負荷以上になりません。 幸いなことに、当社のクラスタリングソフトウェアは、この問題を大幅に排除します。 さらに、ルーターには不均等コストの複数パス機能がまだありますが、まだ使用していません。



5.典型的なBGPタイムアウトは、サーバーが利用できなくなり、バランシングルーターがまだ負荷を分散する状況につながる可能性があります。 しかし、 BFDはこれに役立ちます。 プロトコルの詳細については- ウィキペディアを参照してください。 実際、BIRDに切り替えることにしたのはBFDのためでした。

小計

トラフィックフローチェーンからバランサーを除外することで、機器の節約、システムの信頼性の向上、地域ノードの最小化の維持が可能になりました。 このようなバランススキームの欠点を補うために、いくつかのトリックを適用する必要がありました（これらのトリックについて話す機会がまだあることを願っています）。 しかし、既存のスキームにはまだ余分な要素があります。 そして、私は本当にそれを今年削除して、どうやってそれをしたかを教えてくれることを本当に望んでいます。



ちなみに、この記事を書いている間（より正確にはドラフトのレイアウト）、Habréの同僚はアルゴリズムのバランスについて非常に良い記事を書きました。 読むことをお勧めします！



PS証明書は1回限りなので、「最初に起きた人は誰でも、彼とPOSがシャワーを浴びました」。



以前の出版物：

» ガードiviのフグ

» 非パーソナライズガイドライン：関連付け方法

» 都市別および重量別、またはCDNノード間のバランス調整方法

» 私はGrootです。 イベントの分析を行います

» すべて1つまたはCDNの構築方法