1秒あたり100万PPS-接続性とバランス

前回のRIT ++会議で、 私は幸運にも 、この規模とそのような重要性を持つ会議の最初の講演者になれました。 この記事では、私が報告したすべてのことをもう一度言いたいだけではありません。 こんなに多くの聴衆に初めて話すのは私にとって珍しいことでした。 Webプロジェクトの独自の復元構造をゼロから作成することです。 ほとんどのシステム管理者は、大規模なプロジェクトをゼロから実稼働で開始する機会を与えられません。 ラッキーだ。



すでに書いたように、ステージから計画したことをすべて伝えることはできませんでした。この記事では、これらのギャップを埋めます。そこにいられなかった人にとっては、会議のビデオは誰にも無料で提供されませんでした。 はい、私は長い間Habrのユーザーになりたかったのですが、時間がありませんでした。 5月の休日は時間と力を与えました。 この記事は、多くの構成とグラフでそれほど技術的ではありません-この記事は基本的なものであり、小さな技術的問題のギャップはすべてコメントで埋めることができます。







タスクを設定します ：特定のデータセンター（DC）に依存しない99.9％のフォールトトレラントWebプロジェクトを編成する必要があります。DCの切り替えに二重の冗長性があり、バランシングにフォールトトレランスがあり、実サーバーを非常に迅速に入出力します。 DCの1つがクラッシュした場合、2番目のDCはドロップおよび再送信なしですべてのトラフィックを受け入れる必要があります。 ここでは、前線、障害、バランス、および非常に多くのサーバーの展開についてのみ説明します。 誰もが独自のバックエンド仕様を持っています。



接続予約



私が関わっているプロジェクトは、わずかなグリッチでも非常に重要です。 RPS 400+の上位Runetプロジェクト（Yandex、Mail、Rambler、Poster、Autoなど）を要約すると、合計RPSを取得できます。 ある時点で、すべての卵をさらに1つのバスケット（DC）に入れておけば、非常に美しく美しく落ちることができることが明らかになりました。 モスクワのチュバイのパフを思い出せば、私を理解できます。 サーバーファームを複数のDCに分割する問題の調査を開始しました。 主な問題は、サーバーを同じバックボーンで接続されていない複数のDCに拡散するのではなく、クライアントのトラフィックをあるDCから別のDCにすばやくシームレスに切り替えることです。







すぐに予約します：私たちが選択した実装は、少なくとも/ 23のマスクを持つ独自のASがあり、公式にRIPEを/ 24で2つのネットワークにカットした場合にのみ可能です。 正直なところ、現時点ではどのようになっているのかわかりませんが、同じTTKネットワークが/ 24未満の場合、通過中のアナウンスメントに問題が発生する前に。 適切なハードウェアとEXIST-MAP、NON-EXIST-MAPを使用できる機能を備えたルータとしてCisco ASR 1001を選択しました。 2x DCの例を考えてみましょう。 2つのASRは、両方のDCの接続性が生きていることを知るためだけにトンネルを維持します。 1つのDCから1つのクラスCネットワーク、2番目のDCから2番目のネットワークを発表します。 2番目のDCから接続が切断されたことがわかると、NON-EXIST-MAPを使用して最初のDCから2番目のネットワーク/ 24をアナウンスします。 DCを地理的に分散することをお勧めしますが、これは予算と色に依存します。



これは重要なポイントであり、少し後で説明します。バランスサーバーと実サーバーでは、両方のDCの両方のネットワークからのIPアドレスを絶えず上げる必要があります 。これは重要です。 すべてのDCが正しく接続されていると、ルートは特定のネットワークのアドレスに誰が応答するかによって導かれるため、頭を吹き飛ばさないようにルーター間のトンネルが必要です。 OpenSourceコミュニティにキックしないようにお願いします。これをプレフィックスウェイトを使用してquaggaに実装する方法は知っていますが、プロジェクトは大きく、対応する要件があります。 私はそれが私たちとどのように実装されているかを伝えます。



ルートの変更をテストすると、不快な状況に遭遇しました。 多くのユーザーがアクセスにJuniperを使用しています 。 次に、なぜ不快なのかを説明します。 デフォルトでは、ルートの変更は3分ごとに1回アナウンスされます。 私たちにとって、これは数百ギガバイトのデータの損失です。 アナウンスの時間を短縮する実験を開始しました-最大20秒ですべてが順調でした：アナウンスは私たちの巨大な故郷のさまざまな部分から完璧に速く上がりましたが、このパラメーターを減らした後、DCの1つを失いました。 判明したように、20秒未満のアップリンクの1つにサービスを提供したジュニパーはフラッドと見なされ、削減することはできません。これらはファームウェアの機能です。 結論： 21秒が最適なパラメーターです。



だから それだけです テストした2 DCのフェールオーバー-テスト済み。 ロシアのルートを切り替える実際の時間は、距離と通過時間に応じて25〜60秒です。 この段階では、ルーターを備えた2つのベアDCがあります。 両方のDCにフィリングを入れましょう。



DC内の冗長スイッチング







ここで簡単に説明します。DC内の切り替えは2対2で行われます。ボンドの2つの物理インターフェイスは、実際のIPアドレスを提供するvlanの異なるスイッチを見て、ボンドの2つの物理インターフェイスはバックエンドを提供するvlanの異なるスイッチを見て 最も単純なモードであるボンディングモード= 1を選択しました-失敗するために、ボンディングのゼロ部分を異なるスイッチに分散させました。 一般に、単純なほど信頼性が高くなります。 前面と背面に参加している各サーバー-4つの物理インターフェイス。 図は正面のみを示しています。 スイッチは10Gだけでなくバックアップ電源ケーブルによっても接続され、異なるUPSに接続されます。 モード= 1では、スイッチの特別な構成は必要ありません。これにより、インフラストラクチャ全体の管理が簡素化されます。



バランス調整







実際には、特別な代替手段はなく、IPVSはDR（Direct Routing）モードで選択されました。 上で言ったように、このバランス方法はより安価です。 NATのように、双方向の接続をダンプする魅力を奪いますが、必要なリソースは少なくなります。 Notrackの愛好家は言うでしょう-あなたが接続を100％維持することが重要であるなら、これをしない方が良いです。 IPVSはCentosの標準であり、インストール中に特別なシャーマニズムを必要としません。 遭遇した唯一のニュアンス-デフォルトでは、IPVSは4096の同時接続を受け入れる準備ができています-これは12ビットです。







バランサーが100万の接続を受け入れる準備ができるようにするには、このパラメーターを20ビットに増やす必要があります。 モジュール管理（modprobe.d）のオプションを使用してこれを行うことはできませんでした-ipvsadmは、4096接続を提供する準備ができていることを永続的に主張しました。 srcでペンを実行し、モジュールを再構築する必要がありました。 小さなプロジェクトでは、これはそれほど重要ではありませんが、数十万以上の接続を提供する場合、これは重要です。



バランシングには多くの方法があります。 最も単純なもの-RR（ラウンドロビン）-着信接続を「円形」に実サーバーに送信します。 ただし、WLCタイプ（接続制御によるバランスの取れたバランス）を選択しました。 バランサーの永続性パラメーターを実サーバーのnginxのキープアライブパラメーターと同期すると、接続の調和が取れます。 たとえば、バランサーの永続性が90秒で、Realのnginxのキープアライブが120である場合、90秒後、バランサーはすべてのクライアント接続を別のRealに提供し、古いRealは引き続きクライアント接続を維持します。 1万の確立された接続の30秒のキープアライブで約12万のTIME_WAITがあることを考慮すると（これは完全に正常です、Igor Sysoevと私は電子メールテクノフォーラムの傍観で考えました）、これは非常に重要です。



現在、バランシングテクノロジー自体によると、その仕組み：ドメインのDNSに登録したIPアドレスは、バランサーの外部物理インターフェイスと実サーバーのループバックのエイリアスにブロードキャストされます。 以下はsysctl実サーバーの構成の例です-IPの複製から切り替えが狂わないように、arpアナウンスメントと、必要に応じてソースルーティングを隠蔽する必要があります。 sysctl全体については説明しません。プロジェクトごとに十分に具体的です。DRの詳細に必要なパラメーターのみを示します。



バランサーの場合：

# Fast port recycling (TIME_WAIT) net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 # Local port range maximized net.ipv4.ip_local_port_range = 1024 65535 # Dont allow LB send icmp redirects on local route net.ipv4.conf.eth1.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 # Dont allow LB to accept icmp redirects on local route net.ipv4.conf.eth1.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Ignore ARP net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth1.arp_ignore = 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実サーバーの場合：

 # sysctl.conf net.ipv4.conf.bond0.arp_ignore = 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

255.255.255.255のマスクを持つ実サーバー上の実IPを使用したエイリアスループバックのルーティングは、ネットワークにサービスを提供し、外部にアナウンスするルーターのIPに登録する必要があります。そうしないと、バランシング要求が送信されますが、Realは応答しません。 iproute2とVIPテーブルを使用したスマートなものもありますが、これは設定を複雑にします。



次に、フォールトトレランスのバランスとRealについて説明します。 Keepalivedは非常に論理的に選択されました-IPVS開発者自身は、製品と組み合わせて使用​​することをお勧めします。 通常のスキーム-MASTER + SLAVEはプロジェクトの99％に適していますが、現時点では1つのDCに5つのバランサーがあり、別のDCには3つのバランサーがあります。ブレードの平均コストは120〜14万であるため、少し節約することにしました。 グループが記述されているkeepalived構成セクションを注意深く見ると、2つのマスターに異なるグループを設定し、1mのスレーブに両方のグループを記述すると、1つのスレーブがスキームに従って2つのマスターに対して機能することが明らかになります。スレーブは自分のIPを取得しましたが、2番目のIPが落ちた場合、2番目のIPは同じスレーブによって取得されます。 もちろん、マイナスがあります。両方のマスターが飛び出すと、スレーブに二重の負荷がかかりますが、バランサーにとっては、Realとは異なり、それほど重要ではありません。



そしてもう1つの小さなトリック：CHECK実サーバーはkeepalived構成で提供されます。 単純なTCPでも、HTTPページをプルして200番目の応答を制御することもできますが、MISC_CHECKがあります。 作品は便利で機能的です。 Realサーバーに小さなスクリプトを配置する場合、何が書かれていても問題ありません。ロジックに従って、現在のLAが計算され、バランサーのRealサーバーの動的な重みが生成されます。



展開する



デプロイについて少し。 展開は、サーバー展開の自動化です。 2〜3台のサーバーがある場合はもちろん、自動化を展開しませんが、数十または数百のサーバーがある場合は特に価値があります。サーバーが同じタスクでグループ化されている場合は特にそうです。

前面に2つのグループしかありません。これらは、実際にユーザーにコンテンツを配信するバランサーとnginxを備えた実サーバーです。

 # file top.sls base: '*': - ssh - nginx - etc 'ccs*': - ccs 'lb*': - lbs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの展開システムがあります-人形、チーフ...しかし、私たちはソルト（saltstack.org）を選びました。 仕組み：構成内のソルトサーバーで、サーバーグループを作成し、グループごとに展開計画を作成します。これには、サービスが機能するために必要なシステムユーザーとグループ、すべてのサーバーに存在する必要がある構成ファイル、インストールされたソフトウェアが含まれます...

 # file /srv/salt/etc/init.sls /etc/hosts: file: - managed - source: salt://files/hosts /etc/selinux/config: file: - managed - source: salt://files/selinux.config /etc/snmp/snmpd.conf: file: - managed - source: salt://files/snmpd.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成ファイルに各サーバーに固有のデータが必要な場合、saltには、一意の構成をその場で生成できる柱テンプレートエンジンがあります。 ファーム全体を展開する前に、展開サーバーで正確に開始したため、サーバーファームの形成後、展開が正しく記述されていることを確認できます。 そして、私はあなたにそうアドバイスします。



これはレポートの一部にすぎません。 必ず時間をかけて、Webファームのテスト方法に関する別の記事を書いてください。nginxの最大値をドロップや再送信なしに「絞り」、合成テストと実稼働テストの違いを確認してください。



高負荷で頑張ってください！