9年前のルーター最適化

2004年に始まったノボシビルスク大学のキャンパスネットワーク上のサーバーのライフストーリーと、その最適化とダウングレードの段階についてお話したいと思います。

記事では、10年近く前の出来事についてお話しするという理由だけで、当時は高度なテクノロジーでしたが、多くのことはよく知られています。 同じ理由で、一般に何かが関連性を失いましたが、サーバーがまだ生きており、1000台のマシンのグリッドにサービスを提供しているため、すべてではありません。

ネットワーク

ネットワーク自体は1997年以来存在しています。これは、すべてのホステルが単一のネットワークに統合され、インターネットにアクセスした日付です。 2004年まで、キャンパスネットワークは完全に銅線で構築され、寮間ではリンクがP270ケーブルで転送されました（寮間の距離は350mを超えず、3c905カードを使用した場合のリンクは「100倍」増加しました）。 各建物には独自のサーバーがあり、3つのネットワークカードがありました。 それらのうちの2つは、近隣のサーバー、3番目に接続されたホステルの「ロカルカ」を「見ました」。 合計で、6つすべて（および私たちの大学には非常に多くのホステルがありました）がリングで閉じられ、それらの間のルートはOSPFプロトコルを使用して構築されました。これにより、回線が切断されたときにドロップされたリンクをバイパスするトラフィックを開始できました。 そして、クリッピングが頻繁に発生しました。その後、雷雨が発生し、リンクが切断され、電気技師がチートします。 サーバー自体のサービスは、特にすべてがまだらであるため、あまり便利ではありませんでした：異なる年の486DX4から（はい、2.0.36コアと3comカードの8MBのRAMで、2つの100Mbitリンクを引っ張りましたが、負荷は天井にありました） ipfwadmを使用しないベアルーティングで）AMD K6-2、さらにはP4 2.8Ghzまで。

そのような組織の欠点（今日の標準では非常に信頼性の低いリンクに加えて）は明らかです。ユーザーベースを管理するのは非常に不便です。 アドレスは白で、その数は制限されています。 契約は「生涯」、つまり学生の学習期間全体にわたってIPに結び付けられました。 ネットワークは、各寮の学生数を考慮して元々作成されたサイズに分割されています。 しかし、その後、学生はホステルからホステルに移動し、オートメーション学部は、哲学者よりもはるかに多くのアドレスを必要としました-一般に、恐怖。

ネットワークの「構想」の時点で、プログラマー（またははんだごて）なしでネットワークカードのMACアドレスを変更することは、不可能ではないにしても非常に問題があるため、アクセス制限はMAC-IPのペアにありました。 したがって、/ etc / ethersファイルを最新の状態に保ち、99％の景品愛好家から保存するだけで十分でした。 当時のマネージドスイッチは夢見ていただけで、加入者機器として設置する余裕はありませんでした（ネットワークは学生自身のお金で100％開発していたため、学生はご存知の通り、裕福ではありません）

星印

2004年に、良い機会が見つかりました。都市プロバイダーの1つが、ネットワークとキャンパスネットワーク間のピアリングと引き換えに、すべての建物を無料で光学的に接続することを提案しました。 接続方法-学生のイニシアチブグループが光学の設置に直接関与していましたが、プロバイダーの技術者はそれを消化しただけでした。 その結果、この光学系を使用して、リングではなく星を作ることができました！

そして、ここでアイデアが生まれました-いくつかのギガビットネットワークカードを備えた1つの良いサーバーを配置し、すべてのリンクを1つのブリッジに接続し、1つのフラットネットワークを作成します場所。

PCIバスはそのようなトラフィックを送り出すことができず、マザーボードに非常に多くのPCIコネクタがないために必要な6-8ギガビットポートを取得できなかったため、PCI-X 133Mhzバスに2x Intel Quadポートサーバーアダプターを使用することが決定されました。 3つのPCI-X 133が存在するため、これらのネットワークにSupermicro X6DHE-XG2マザーボードを持ち込む必要がありました。

そして、RHELAS 2.1がサーバーにインストールされ、ブリッジが開始され、ネットワークが1つの大きな/ 22に接着されます。 そして、次のようなルールを使用して、数百のアドレスへのアクセスを制限すると、

iptables -A FORWARD -s abcd -j REJECT





サーバーの負荷は不適切な値に跳ね返ります。 サーバーが対応していませんか？

最適化1

インターネットでの検索では、その後に出現したプロジェクトのみが示唆されます-ipset 。 はい、これがまさにあなたが必要とするものであることが判明しました。 iptablesの同じタイプのエントリを多数削除することが可能であるという事実に加えて、macipmapを使用してIP-MACをバインドすることが可能になりました。

ブリッジの機能の1つは、場合によってはブリッジを通過するパケットがFORWARDチェーンに落ちたが、そうではなかったということです。 インターフェース間の「ルーティングされた」パケットはFORWARDに入り、「ブリッジされた」パケット（つまり、br0に入ってすぐにbr0を出るパケット）は入らないことが判明しました。

解決策は、フィルターの代わりにマングルテーブルを使用することでした。

また、特定のアドレスをMACだけでなく、ネットワークユーザーが住んでいたホステルにもバインドしました。 iptables physdevモジュールを使用して行われ、次のようになりました。

 iptables -t mangle -A PREROUTING -m physdev --physdev-in eth1 -m set --set IPMAC_H1 src -j ACCEPT iptables -t mangle -A PREROUTING -m physdev --physdev-in eth2 -m set --set IPMAC_H2 src -j ACCEPT ... iptables -t mangle -A PREROUTING -i br0 -j DROP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

光「スター」はオプトコンバーターを使用して構築されたため、独自のネットワークカードは各ビルで「見え」ました。 そして、最初のホステルのユーザーのMAC-IPペアのみをIPMAC_H1セットに追加し、2番目のホステルのIPMAC_H2セットに追加するなどの必要がありました。

iptables内でルール自体の順序を変えて、ユーザーがよりアクティブなホステルを記述するルールが高くなり、パケットがチェーンをより速く通過できるようにしました。

最適化2

その結果、すべての相互コミュニティおよび外部トラフィックが最終的にサーバーを通過し始めたため、サブスクライバーが切断された場合、またはIP-MACペアが一致しない場合、アイデアを思い付きました。実際に、ネットワークは機能しません。 難しいことではないようでした。 ポート80に向かうDROPパケットの代わりに、MARKパケットを作成してから、DNATを使用してマークされたパケットをローカルWebサーバーにリダイレクトする必要がありました。

最初の問題は、パッケージを単純にWebサーバーにリダイレクトすると、99％のWebサーバーがページが見つからなかったと応答することでした。 なぜなら、ユーザーがark.intel.com/products/27100にアクセスしてWebサーバーを有効にした場合、products / 27100ページが存在する可能性は低く、せいぜい404エラーが表示されるだけだからです。リクエストを発行したCのデーモン Location: myserverru





その後、この松葉杖はmod_rewriteを使用したより美しいソリューションに置き換えられました。

2番目の、そして最も重要な問題は、natモジュールがカーネルにロードされるとすぐに、ロードが再びジャンプすることでした。 もちろん、conntrackテーブルのせいであり、非常に多くの接続とppsがあるため、既存の鉄はピーク時に取り出せませんでした。

サーバーが対応していませんか？

考え始める。 目標は非常に興味深いものですが、既存のハードウェアでは機能しません。 -t raw -j NOTRACK



を使用すると-t raw -j NOTRACK



ましたが、それほどではありません。 解決策は次のとおりです。NATパケットは中央ルーターではなく、p2pサーバー、ゲームサーバー、ジャバーサーバー、または単にアイドル状態のサービスなど、さまざまなサービスにまだ使用されていた古いマシンの1つにあります。 このサーバーの負荷が急増した場合、最悪の場合、サブスクライバーはブラウザーウィンドウで切断されたというメッセージを受信しません（または、IPが登録されたMACと一致しない）。これは他のネットワークユーザーの作業に影響しません。 また、NATを使用してこのサーバーにユーザートラフィックを配信するために、次のコマンドが使用されました。

iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j ROUTE --gw abcd





ゲートウェイアドレスを単に置き換え、パケットをさらに送信し、残りのチェーンをバイパスしました。

一般に、フィルタタイプの残りのチェーンを通過することを心配せずに、この方法で「不快な」パッケージをサードパーティのサーバーに送信することは非常に便利でしたが、カーネルアーキテクチャの変更により、patch-o-maticからのこのパッチはサポートされなくなりました。

解決策：必要なパケットを0x1でマークしてから、ipルールfwを使用して、「その他」のルーティングテーブルにパケットを送信します。ここで、唯一のルートはNATを備えたサーバーです

 iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 0x1 ip route flush table 100 ip route add via abcd table 100 ip rule add fwmark 0x1 lookup 100
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、「良い」トラフィックはスキップされ、「悪い」ユーザーにはブロックに関する情報を含むページが表示されました。 また、IP-MACが一致しない場合、ユーザーはログイン/パスワードを入力して現在のMACに再バインドできます。

最適化3

このアクションは、メガバイトのトラフィック中にホステルで行われます。 つまり、キャッシュフリー、オンラインアクティブ、IT先進のユーザー環境です。 これは、単純なIP-MACバインディングではもはや十分ではなく、インターネットトラフィックの盗難の事例が広まっていることを意味します。

唯一の正気なオプションはvpnです。 しかし、その時点までにキャンパスネットワークは6ダースの都市オペレーターと無料のピアリングを行っていたため、VPNサーバーを介してピアツーピアトラフィックを駆動することはできなかったため、簡単に削除できませんでした。 もちろん、インターネット上で-VPN経由で、ピアリングおよびLANで-ルートを含むバッチファイルとして、広く普及した方法が可能になりました。 しかし、バッチファイルは非常にい決定でした。 私たちは、当時ほとんどのオペレーティングシステムに「組み込まれていた」RIPv2のオプションを検討しましたが、アナウンスの信頼性に関する未解決の問題が残っていました。 追加の設定がなければ、誰でもルートを送信でき、当時人気のあったWindowXPとその「RIPリスナー」には設定がまったくありませんでした。

その後、「非対称VPN」が「発明されました」。 インターネットにアクセスするために、クライアントはユーザー名/パスワードを使用してサーバーへの通常のvpn-pptp接続を確立し、設定の[リモートネットワークでゲートウェイを使用する]チェックボックスをオフにします。 アドレス192.0.2.2はトンネルのクライアントエンドに発行され、すべてのクライアントは同じアドレスを持ち、後で示すように、それはまったく意味がありませんでした。

VPNサーバー側で、/ etc / ppp / ip-upスクリプトが変更されました。これは、認証およびインターフェースの起動後に実行されます

 PATH=/sbin:/usr/sbin:/bin:/usr/bin export PATH LOGDEVICE=$6 REALDEVICE=$1 [ -f /etc/sysconfig/network-scripts/ifcfg-${LOGDEVICE} ] && /etc/sysconfig/network-scripts/ifup-post ifcfg-${LOGDEVICE} [ -x /etc/ppp/ip-up.local ] && /etc/ppp/ip-up.local "$@" PEERIP=`/usr/local/bin/getip.pl $PEERNAME` if [ $LOGDEVICE == $PEERIP ] ; then ip ro del $PEERIP table vpn > /dev/null 2>/dev/null& ip ro add $PEERIP dev $IFNAME table 101 else ifconfig $IFNAME down kill $PPPD_PID fi exit 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、PEERNAME（接続したログイン）を持つユーザーがデータベースからPEERIP変数にデータベースからプルしたIPアドレス。このアドレスがVPNサーバーへの接続（LOGDEVICE）が確立されたIPと一致する場合、このIPへのすべてのトラフィックは、テーブル101を介してIFNAMEインターフェイスにルーティングされます。また、テーブル101では、デフォルトゲートウェイは127.0.0.1です。

すべてのルーティングされたトラフィックは、ルールによってテーブル101にラップされます

ip ru add iif eth0 lookup 101





その結果、vpnサーバーに到達したトラフィックと、vpnサーバーに到達しない次のトラフィック（デフォルトではローカルテーブルに送信されます）がテーブル101に送信されます。そこで、pppトンネルに沿って「拡散」します。 そして、彼が正しいものを見つけられない場合、彼は単にドロップします。

プレート101の結果の例（ip r sh ta 101）

 [root@vpn ~]# ip route show table 101 abcd dev ppp2 scope link abce dev ppp6 scope link abcf dev ppp1 scope link default via 127.0.0.1 dev lo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで残っているのは、「インターネット」インターフェースから中央ルーターのvpnゲートウェイへのすべてのトラフィックをラップすることです。ユーザーはVPNに接続しないとインターネットにアクセスできません。 さらに、残りのトラフィック（ピアツーピア）はIPoEを実行し（つまり、「通常の」方法で）、VPNサーバーをロードしません。 追加のピアツーピアネットワークが表示される場合、ユーザーはbatファイルを編集する必要はありません。 繰り返しますが、少なくともIP、少なくともポートなどの一部の内部リソースへのアクセスは、VPNを介して実行できます。パケットをVPNサーバーにラップするだけです。

この手法を使用すると、攻撃者はIP-MACを置き換えることで確実にトラフィックをインターネットに送信できますが、vpnトンネルが発生していないため、何も戻すことができません。 置換の意味をほぼ完全に無効にしているもの-他人のIPから「インターネットをサーフィン」することはできません。

クライアントコンピューターがVPNトンネルを介してパケットを受信できるようにするには、WindowsのレジストリでIPEnableRouter = 1キーを、Linuxでrp_filter = 0を設定する必要がありました。 そうでない場合、OSは、要求が送信されたインターフェースからではなく、応答を受け入れませんでした。

vpn havatloサーバーレベルceleron 2Ghzへの最大700の同時接続では、メガバイト料金の時点でppp内のインターネットトラフィックがそれほど大きくなかったため、実装コストはほぼゼロです。 同時に、ピアツーピアトラフィックは合計で最大6ギガビット/秒の速度で実行されました（S604のXeon経由）

作品

2006年、RHELAS 2.1は新しくリリースされたCentOS 4に置き換えられました。建物の中央スイッチはDES-3028に変更され、DES-1024は加入者側のままでした。 DES-3028のアクセス制御が正しく機能しませんでした。 ACLを使用してip-macをポートにバインドするために、一部のホステルには300を超えるコンピューターがあったため、256エントリが欠落していました。 大学がネットワークを「合法化」したため、機器の変更が問題になりました。現在、大学のキャッシュデスクで支払う必要があったため、機器に戻るお金は割り当てられませんでした。割り当てられた場合、1年後と競争（購入しない場合）必要なもの、安いもの、またはロールバックが多い場所）。

サーバーが壊れています

そして、サーバーが故障しました。 むしろ、マザーボードは燃え尽きました（ワークショップの結論によると、ノースブリッジが死にました）。 交換するものを集める必要がありますが、お金はありません。 つまり、無料でいいと思います。 そして、PCI-Xネットワークを挿入できるようにします。 幸いなことに、私の友人はサーバーを銀行から貸し出してくれましたが、PCI-X 133スロットが2つしかありませんでしたが、マザーボードはシングルプロセッサで、Xeonはなく、Socket 478 Pentium 4 3Ghzです。

ネジ、ネットワークカードを投げます。 開始-動作しているようです。

しかし、softirqは2つの疑似核の合計の90％を「食べ」（プロセッサに1つのコアがあり、ハイパートレッドが有効になっている）、pingが3000にジャンプし、コンソールも不可能に「死ぬ」。



ここにあるように見えますが、サーバーは古くなっており、休憩する時間です。

最適化4

oprofileで武装した私は、「過剰な咳をし始めます」。 一般に、このサーバーとの「通信」の過程でoprofileは非常に頻繁に使用され、1回以上役立ちました。 たとえば、ipprofileを使用する場合でも、iphashではなくipmapを使用しようとします（可能な場合）。oprofileを使用すると、パフォーマンスの違いがどれだけあるかを確認できます。 私のデータによると、2桁、つまり200から400回航行しました。 また、異なる時間にトラフィックを計算するときに、プロファイリングに焦点を当てて、ipcad-ulogからipcad-pcapに切り替えてから、nflowに切り替えました。 私はもうipt_NETFLOWを使用していなかったため、「無制限のインターネット」の時代に突入しました。SORMのNetflowトップレベルプロバイダーはそこに問題があるかどうかを書きました。 実際に、oprofileを使用すると、natがオンになったときにip_conntrackがメインのリソースイーターであることが明らかになりました。

一般に、今回のoprofileは、プロセッササイクルの60％がe1000カーネルモジュール（ネットワークカード）によって占有されていることを示しています。 まあそれで何をする？ e1000.txtで推奨

options e1000 RxDescriptors=4096,4096,4096,4096,4096,4096,4096,4096,4096,4096 TxDescriptors=4096,4096,4096,4096,4096,4096,4096,4096,4096,4096 InterruptThrottleRate=3000,3000,3000,3000,3000,3000,3000,3000,3000,3000





2005年に刻まれました。

git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.gitでe1000の重要な変更をすばやく確認しても、結果は得られませんでした（つまり、変更はありますが、バグ修正またはコード）。 念のため、カーネルは引き続き更新されましたが、結果は生成されませんでした。

カーネルにはCONFIG_HZ_100=y



もあり、値が大きくなると、結果はさらに悪化します。

Oprofileはまた、ブリッジモジュールがサイクルのかなりの部分を占めると述べています。 そして、IPアドレスはいくつかの建物に散らばって散らばっており、セグメントに分割することはもはや不可能なので、それなしではどこにも見えません（サーバーなしですべてを1つのセグメントに結合するオプションは考慮されません、制御が失われるため）

橋を壊してproxy_arpを使用することを考えています。 特に、flood_fdbを使用してDES-3028のバグを検出した後、長期間これを実行したかったためです。 原則として、次の形式ですべてのアドレスをルーティングテーブルにロードできます。

 ip route add abc1.d1 dev eth1 src 1.2.3.4 ip route add abc1.d2 dev eth1 src 1.2.3.4 ... ip route add abc2.d1 dev eth2 src 1.2.3.4 ip route add abc2.d2 dev eth2 src 1.2.3.4 ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜなら、どのサブスクライバーがどこにあるべきかがわかっているからです（データベースに格納されています）

ただし、建物だけでなく、建物のノードスイッチポートにもIP-MACバインディングを実装したかった（繰り返しますが、DES-1024タイプの非管理デバイスはサブスクライバーにあります）

そして、手はdhcp-relayとdhcp-snoopingに対処するために手を差し伸べます。

含まれているスイッチ：

 enable dhcp_relay config dhcp_relay option_82 state enable config dhcp_relay option_82 check enable config dhcp_relay option_82 policy replace config dhcp_relay option_82 remote_id default config dhcp_relay add ipif System 10.160.8.1 enable address_binding dhcp_snoop enable address_binding trap_log config address_binding ip_mac ports 1-28 mode acl stop_learning_threshold 500 config address_binding ip_mac ports 1-24 state enable strict allow_zeroip enable forward_dhcppkt enable config address_binding dhcp_snoop max_entry ports 1-24 limit no_limit config filter dhcp_server ports 1-24 state enable config filter dhcp_server ports 25-28 state disable config filter dhcp_server trap_log enable config filter dhcp_server illegal_server_log_suppress_duration 1min
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーで、ブリッジからインターフェイスを削除し、それらのIPアドレス（IPのないインターフェイス）を削除し、arp_proxyを有効にしました



isc-dhcpの構成

 log-facility local6; ddns-update-style none; authoritative; use-host-decl-names on; default-lease-time 300; max-lease-time 600; get-lease-hostnames on; option domain-name "myserver.ru"; option ntp-servers myntp.ru; option domain-name-servers mydnsp-ip; local-address 10.160.8.1; include "/etc/dhcp-hosts"; #   MAC-IP   "host hostname {hardware ethernet AA:BB:CC:55:92:A4; fixed-address wxyz;}" on release { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); log(info, concat("***** release IP " , ClientIP)); execute("/etc/dhcp/dhcp-release", ClientIP); } on expiry { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); log(info, concat("***** expiry IP " , ClientIP)); execute("/etc/dhcp/dhcp-release", ClientIP); } on commit { if exists agent.remote-id { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)); set ClientPort = binary-to-ascii(10,8,"",suffix(option agent.circuit-id,1)); set ClientSwitch = binary-to-ascii(16,8,":",substring(option agent.remote-id,2,6)); log(info, concat("***** IP: " , ClientIP, " Mac: ", ClientMac, " Port: ",ClientPort, " Switch: ",ClientSwitch)); execute("/etc/dhcp/dhcp-event", ClientIP, ClientMac, ClientPort, ClientSwitch); } } option space microsoft; #   - option microsoft.disable-netbios-over-tcpip code 1 = unsigned integer 32; if substring(option vendor-class-identifier, 0, 4) = "MSFT" { vendor-option-space microsoft; } shared-network HOSTEL { subnet 10.160.0.0 netmask 255.255.248.0 { range 10.160.0.1 10.160.0.100; #    option routers 10.160.1.1; option microsoft.disable-netbios-over-tcpip 2; } subnet abc0 netmask 255.255.252.0 { option routers abcd; option microsoft.disable-netbios-over-tcpip 2; } subnet 10.160.8.0 netmask 255.255.255.0 { #    dhcp-relay   } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

dhcp-eventファイルでは、agent.circuit-id、agent.remote-id、IP、およびMACの有効性がチェックされ、すべてが正常である場合、ルートは目的のインターフェースを介してこのアドレスに追加されます

プリミティブdhcp-eventの例：

 #hostel 1 if ($ARGV[3] eq '0:21:91:92:d7:55') { system "/sbin/ip ro add $ARGV[0] dev eth1 src abcd"; } #hostel 2 if ($ARGV[3] eq '0:21:91:92:d4:92') { system "/sbin/ip ro add $ARGV[0] dev eth2 src abcd"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは$ ARGV [3]のみがチェックされます（つまり、agent.remote-id、またはDHCP要求を受信したスイッチのMAC）。ただし、データベースなどから有効な値を受信することで、他のすべてのフィールドをチェックすることもできます



その結果、以下が得られます。

1）DHCPを介してアドレスを要求しなかったクライアント-管理されていないスイッチを超えないため、IP-MAC-PORT-BINDINGはそれを通過させません。

2）MACがわかっている（データベース内にある）クライアントがポートまたはスイッチと一致しない-このMACに接続されたIPを受信するが、そのMACへのルートは追加されないため、proxy_arpはアドレスが既に取得されていることを「答え」、アドレスすぐにリリースされます。

3）MACが不明なクライアントは、一時プールからアドレスを受け取ります。 これらのアドレスから、情報を含むページへのリダイレクトがあります。ここでは、ログイン/パスワードを使用してMACを再登録することもできます。

4）そして最後に、MACが既知であり、スイッチおよびポートへの接続と一致するクライアントがそのアドレスを受信します。 Dhcpスヌーピングは、スイッチ上のimpbテーブルに動的バインディングを追加し、サーバーは、以前のブリッジの目的のインターフェースを介してこのアドレスへのルートを追加します。



リースが終了するか、アドレスが解放されると、スクリプト/ etc / dhcp / dhcp-releaseが呼び出されます。その内容は非常に原始的です：

 system "/sbin/ip ro del $ARGV[0]";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特に第2項に、小さなセキュリティ上の欠陥があります。 dhcpサーバーから提供されたアドレスがビジーであるかどうかをチェックしない非標準のdhcp-clientを使用する場合、アドレスは解放されません。 もちろん、サーバーは目的のインターフェイスを介してこのアドレスへのルートを追加しないため、ユーザーはルーターを越えて外部ネットワークにアクセスできませんが、スイッチはそのポートでこのMAC-IPペアのロックを解除します。

dhcpd.confのクラスを使用してこの問題を回避できますが、これにより構成ファイルが大幅に複雑になり、それに応じて古いサーバーの負荷が増大します。 各サブスクライバーに対して、取得するのがやや難しい条件で独自のクラスを作成し、それから独自のプールを作成する必要があるためです。 実際にどれだけ負荷を増やすかを試してみる計画がありますが。



したがって、IP-MACペアの対応は、アドレスを発行するときにDHCPによって「監視」され、「無効な」MAC-IPからのアクセスはスイッチによって制限されることが判明しました。 これで、ブリッジだけでなくmacipmapもサーバーから削除し、6つのセット（「最適化1」から）をすべてのパブリックIPアドレスを含む1つのipmapに置き換えることができました。また、-m physdevを削除することによっても。

サーバーインターフェイスも無差別モードから通常モードに切り替わり、負荷もわずかに減少しました。



つまり、ブリッジを分解するこの全体の手順により、サーバーの全体的な負荷がほぼ2倍に削減されました。Softirqは現在50〜100％ではなく、25〜50％です。同時に、ネットワークへのアクセス制御が改善されただけです。

最適化5

最後の最適化の後、負荷は著しく低下しましたが、奇妙なことに気づきました：iowaitが増加しました。それほど多くない、0-0.3％から5-7％。これは、このサーバーで実際にディスク操作が行われないという事実を考慮に入れています。パケットをスローするだけです。



（青いユーザー時間-カーネルのコンパイル）

iostatは、800-820 Blk_wrtn / sでディスクに一定の負荷が

あることを示しました。書き込み可能なプロセスの検索を開始しました。フルフィルメント

 echo 1 > /proc/sys/vm/block_dump
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

奇妙な結果をもたらした：犯人は

 kjournald(483): WRITE block 76480 on md0  md0_raid1(481): WRITE block 154207744 on sdb2 md0_raid1(481): WRITE block 154207744 on sda3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ext3はモードdata=writeback, noatime



であり、ログを除いて、ディスクには何も書き込まれません。しかし、昨日書き込まれたログは今日書き込まれ、そのボリュームは増加していません。つまり、iowaitも増加する必要はありませんでした。

私は自分の頭の中のステップ、私がやっていること、iowaitに影響を与える可能性のあるものをスクロールし始めました。その結果、syslogを停止し、iowaitが急激に〜0％に低下した

ため、dhcpがメッセージでメッセージを乱雑にしないように、log-facility local6に送信し、syslog.confに書き込みました。

 *.info;mail.none;authpriv.none;cron.none;local6.none /var/log/messages local6.info /var/log/dhcpd.log
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

syslogを介して書き込む場合、各行で同期が行われることが判明しました。dhcpサーバーへの要求は非常に多く、ログを取得する多くのイベントが生成され、多くの同期が呼び出されます。

修正する

 local6.info -/var/log/dhcpd.log
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の場合、iowaitは10〜100倍減少し、5〜7％ではなく、0〜0.3％になりました。

最適化の結果：





なぜこの記事。

まず、多分誰かがそれから自分自身のための有用な解決策を引き出すでしょう。ここで説明した出来事のほとんどはグバン以前の時代のものであり、「グーグルレシピ」はあまり役に立ちませんでしたが、私はここでアメリカを発見しませんでした。

第二に、開発者はコードを最適化する代わりに計算能力の向上に取り組んでいるという事実に常に対処する必要があります。この記事は、必要に応じて、何度もテストされたコードでエラーを見つけて管理できるという事実の例になります。サイト開発者の90％は、自分のマシンでサイトの作業を確認し、それを運用環境に入れます。その後、負荷がかかると全体が遅くなります。管理サーバーをからかいます。この場合、サーバーを最適化することにより、コードが最初に最適に書かれていないと、ほとんど達成できません。そして、新しいサーバー、または別のサーバーとバランサーを購入します。その後、バランサーのバランサーなど。また、内部のコードは最適ではなく、永遠に残ります。もちろん、現在の現実では、コードの最適化は大規模なキャパシティビルディングよりも高価であり、しかし、膨大な数の「自家製」のIT専門家の出現により、「不正なコード」の量は深刻になります。

ノスタルジックから：私は棚に古いラップトップ、P3-866 2001（誰かがこれに何か言うならパナソニックCF-T1）を持っていますが、今ではそのサイトを見ることすらできません。4コア/ 4ギグを必要とする今日のモンスターに劣らないゲームプレイの観点から、ZX-Spectrumの面白いおもちゃを愛を覚えています