我在兩個資料中心之間同步大量資料時遇到問題。兩台機器都有千兆位元連線並且沒有完全佔用，但我能達到的最快速度是 6 到 10 Mbit => 不可接受！
昨天我做了一些追蹤路由，顯示 LEVEL3 路由器上有巨大的負載，但問題已經存在了幾週，而且高回應時間已經消失（20 毫秒而不是 300 毫秒）。
我如何追蹤它以找到實際的慢速節點？考慮過使用更大的套件進行追蹤路由，但這行得通嗎？
此外，此問題可能與我們的其中一台伺服器無關，因為到其他伺服器或用戶端的傳輸速率要高得多。實際上辦公室 => 伺服器比伺服器 <=> 伺服器！
任何想法表示讚賞;)
更新
我們實際上使用 rsync 透過 ssh 來複製檔案。由於加密往往有更多瓶頸，我嘗試了 HTTP 請求，但不幸的是它同樣慢。
我們與其中一個資料中心簽訂了 SLA。他們表示，他們已經嘗試更改路由，因為他們說這與流量路由通過的廉價網路有關。確實，它將通過“廉價網路”進行路由，但反之亦然。我們的方向通過 LEVEL3，另一條路通過 lambdanet（他們說這不是一個好的網路）。如果我做對了（我是網路中間人），他們模擬了一條更長的路徑來強制通過 LEVEL3 進行路由，並且他們在 AS 路徑中宣布了 LEVEL3。
我基本上想知道他們是否是對的，或者他們只是想放棄自己的責任。問題是這個問題存在於兩個方向（雖然不同的路線），所以我認為這是我們的主機的責任。老實說，我不相信有一個 DC2DC 連線只能處理數週的 600kb/s - 1.5 MB/s！問題是如何檢測這個瓶頸在哪裡
答案1
如果您透過公共網路上的慢速連結進行路由，那麼幾乎您唯一的選擇就是強行繞過它。最簡單的方法是嘗試在兩個端點之間傳輸文件，其中一個是「A 點」（資料的來源），另一個是「A 點」。中間位點該地點與您的目的地「B 點」不在同一地點。
一旦你找到一個“C點”，它就是一個伺服器不是透過您面對的慢速網路路由器進行路由，您可以在 A 點和 C 點之間設定 VPN，以便流量「繞過」慢速節點。
如果您對 ISP 具有較高的商業價值 ($$$$$$) 或影響力，您也可以直接向 3 級解決該問題。品質或網路飽和，因為如果他們不能、不會或無法擴展與下游或在其節點上產生爭用的其他一級提供者的對等協議，那麼他們對此無能為力。
既然您說「辦公室到伺服器」連結速度更快，您可以嘗試使用一台功能中等的電腦（雙核心伺服器等級系統應該沒問題）在「辦公室」網站設定VPN。
哦，還有！如果「A 點」和「B 點」之間的延遲（端對端）非常高（在伺服器領域，大於 100 毫秒就很高），您應該確保您沒有使用聊天網路協議。 Samba（也稱為 SMB 或 Windows 檔案共用）是極為健談；其他「同步」協議也可能很囉嗦。
閒聊協定是那些需要大量同步「來回」往返才能傳輸資料的協定。如果您的協定過於繁雜，那麼無論連結的速度有多快，僅延遲就會成為傳輸的瓶頸。
要確定閒聊是否真正影響吞吐量，您可以做的一件事是使用已知的不健談的用於測試傳輸的協議，例如 HTTP。因此，嘗試透過「慢速」Level3 路由器從「A 點」到「B 點」的常規舊 HTTP，如果延遲很高但吞吐量仍然不錯，那麼您知道您的傳輸速度慢的原因是您的協定太繁瑣，因此您需要更改協定。
因此，讓我透過簡要定義和解釋來結束討論三種網路障礙以及為什麼任何人其中可能對這個問題負責：
潛伏-- 資料封包從您的一端到達另一端需要多長時間。在大多數情況下，您無法直接改善延遲，除非您的一台電腦超載以至於其網路堆疊、核心或應用程式產生顯著的額外延遲。公共 Internet 上的大多數延遲源自 Internet 路由器，而不是來自您的電腦或端點。
頻寬-- 頻寬是電腦與端點之間最慢連結的最大吞吐量。在大多數現代網路中，頻寬並不是真正的限制，因為早在頻寬成為真正問題之前，其他網路障礙就已經出現並減慢了網路速度。
資料包遺失-- 封包遺失可能會增加感知到的可靠資料封包（例如 TCP）的延遲，通常是由於嚴重飽和的連結由於緩衝區已太滿而必須將封包從 TCP 傳輸或接收緩衝區中丟棄的結果。此外，「時間敏感」封包可能會發生封包遺失，就像幾乎所有 TCP 封包的情況一樣，因為如果封包在截止時間之後到達，則會被丟棄。如果較大的 TCP 封包被分段為多個 IP 資料報，且接收方的 TCP 協定只能等待固定的時間讓所有分段到達，然後決定中止接收資料包，就會發生這種情況。因此，資料包遺失間接源自飽和問題（其中是頻寬問題），或也來自硬體問題或故障。
源自基本網路損傷的是您可以採取的緩解措施，以在不改變基本損傷的情況下提高程序的可靠性，因為大多數時候，您幾乎無法或根本無法控制它們：
緩解措施之一是讓你的協議不那麼囉嗦（或者，從系統整合的角度來看，使用現有的協定比您目前的解決方案更簡潔）。端點之間同步資料所需的「往返」越少，您的情況就越好—就這樣。某些協定可以設計為需要可變的同步頻率 - 如果是這種情況，當您偵測到高延遲或資料包遺失時，您應該盡可能動態地降低同步頻率。減少閒聊有助於減少延遲和資料包遺失，但不能解決頻寬上限問題。
緩解措施之二是配置所有躍點（在管理/硬體層級直接控制的躍點）以使用最佳可用的活動佇列管理 (AQM) 演算法，目前是公平佇列控制延遲 AQM。這在 Linux 核心 3.5 或更高版本中作為 qdisc 實作提供fq_codel，並且它的作用是動態的減少發送和接收緩衝區的大小，以減少這些緩衝區不可避免地產生的延遲。這可以減少資料包遺失並有助於應對使用 TCP 協定的延遲，因為如果您最大限度地減少資料包在透過連結發送之前必須經歷的等待時間，則分段資料包過期的可能性較小。請注意，此緩解措施僅在節點「飽和」時才產生任何影響（即，如果 TCP 緩衝區為空，則沒有效果）。當資料寫入網路套接字的速率超過上行鏈路的傳輸速率時，節點就會飽和。 TCP 堆疊對這種情況的典型回應是增加緩衝區，這實際上會產生負面影響，因為它會增加延遲，並導致各種問題 - 因此 fq_codel 有助於緩解這種情況。
這兩種緩解措施都有助於解決所有三個基本網路障礙，沒有繞過故障節點的路由，以及沒有更改任何硬體或聯絡 ISP。