要理解DC/OS的服務發現與負載均衡策略，首先要理解DC/OS的分層和區域劃分。但是，DC/OS隨著集群及組網規模的不同，業務場景的不同，其分層和區域劃分策略也不相同，進而影響服務發現與負載均衡的選型策略，在實際應用中應根據具體需求做出決策。

在闡述DC/OS為服務發現與負載均衡所提供的各種實現之前，我們先想像一下下述場景：

• 應用集群都是內部的TCP服務調用負載均衡，不需要Layer 7的特性。

• 應用集群需要對外提供TCP和（或）HTTP服務調用。

• 應用集群需要Layer 7的負載均衡特性，如：TLS Termination，zero-downtime deployments， HTTP sticky sessions，load balancing algorithm customization，network ACLs，HTTP basic auth，gzip compression等。

• 應用集群的其它其它服務發現與負載均衡需求。

針對上述場景，DC/OS提供了VIPs（Minuteman），Marathon-LB，Mesos-DNS等服務組件及策略。

• VIPs（Minuteman）是一個4層負載均衡實現，用於DC/OS集群內部Mesos任務之間大多數TCP流量的負載均衡。

• Marathon-LB（MLB）是一個基於HAProxy實現的，為Marathon提供輕量級的TCP/HTTP路由和負載均衡的服務。

• Mesos-DNS是一個簡單的基於DNS的服務發現工具，可用於Mesos任務之間服務發現。

VIPs

DC/OS提供了一個名為Minuteman的伺服器端內部微服務之間的東-西向（區分於Client-Server的南-北向）4層負載均衡。為了易於服務的配置和發現，DC/OS採用命名（name-based）VIPs來定位服務。因此，客戶端訪問服務時連接的是一個服務地址而不是具體的IP地址，同時DC/OS可以很容易的將指向一個命名VIP的調用請求映射到多個具體的IP地址和埠，從而實現負載調度。採用命名VIPs的另一個好處是可以避免與基於IP的VIP產生衝突，在服務安裝時可以自動創建。

關於VIPs的基本概念，請參考《DCOS中的容器網路負載均衡與服務埠配置策略》一文。

基於VIPs的負載調度

在應用的埠定義中添加VIP_$IDX標籤，可以讓應用服務啟用4層負載（前提之一是應用通過健康檢查）。應用啟動時，DC/OS會將該VIP配置分發到集群中的所有節點，這些節點都在負載平衡過程中充當決策者。集群所有節點上都運行著一個進程，當標記為該VIP的數據包到達時，此進程會跟蹤這些應用服務的可用性和可訪問性，以嘗試向正確的後端發送請求。

警告

• 不要為節點之間的流量添加防火牆過濾。

• 不要更改ip_local_port_range。

• 必須安裝ipset包。

• 必須使用支持的操作系統。

持久化連接

建議在使用VIPs方案時，對長連接做持久化，否則可能很快就會佔滿TCP套接字表。Linux上的默認允許源連接使用本地埠的範圍是從32768到61000，也就是在給定源IP和目標地址埠對之間可以建立28232個連接。TCP連接必須在回收之前經過等待時間狀態，Linux內核的默認TCP時間等待周期為120秒。考慮到這一點，只要以235個新連接/秒的速度創建，則120秒左右就會耗盡連接表。

健康檢查

應用必須正常運行並通過健康檢查時，VIPs負載調度才可用。不推薦使用TCP檢查，因為它僅檢查埠是否可用，可能並不能真正確認服務是正常可用的。

注意：在Docker容器應用中使用command健康檢查時，command命令是在容器內運行的，如果使用類似curl的命令，則命令必須已安裝或以RW模式掛載了節點上的/opt/mesosphere路徑。

潛在的問題

• IP Overlay

  如果指定的VIP地址在網路中的其他位置使用，則可能會出現問題。雖然VIP是一個3元組，但最好確保專用於VIP的IP僅供負載均衡使用，而不會在網路中配置它用。因此，應選擇遵循RFC1918範圍內的IP。

• IPSet

  在系統內必須安裝ipset。如果沒有，可能會看到以下錯誤：

[error] Unknown response: {ok,"iptables v1.4.21: Set minuteman doesn"t exist.

Try `iptables -h" or "iptables --help" for more information.
"}

埠

埠61420和61421必須打開，負載均衡才能正常工作。由於負載均衡維護部分網格，它需要確保節點之間的連接不受阻礙。

連接表耗盡

如果出現前面描述的行為正在耗盡連接表，則會在日誌中看到各種錯誤。可以通過設置兩個sysctl來緩解這個問題，但它不會消除警告。

• net.netfilter.nf_conntrack_tcp_timeout_time_wait = 0 - 可以將其設置為0，但time_wait狀態可能會中斷其他應用程序對連接的跟蹤。

• net.ipv4.tcp_tw_reuse = 1 - 此sysctl可能是危險的，它會打破防火牆以及NAT。儘管，如果防火牆正確實現了對TCP時間戳的跟蹤，這個問題將不會存在，但是不要設置net.ipv4.tcp_tw_recycle這個sysctl，因為它不兼容RFC，將打破防火牆對連接的跟蹤。

更多信息可參考：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt。

調試

負載均衡在DC/OS集群中的每個節點上提供幾個介面用於收集統計信息。介面URI為：http://localhost:61421/metrics。

實現

本地進程大約每5秒輪詢一次主節點，主節點也將此節點緩存5秒，因此，更新的傳播時間限制為大約11秒。這種情況僅適用於新的VIPs，對於故障節點不適用。

Marathon-LB

關於Marathon-LB的詳細信息，請參考前文《微服務彈性計算平台DCOS的服務入口—Marathon-LB》。作為對比，這裡再次提及，Marathon-LB的應用場景非常靈活，例如：

• Marathon-LB可用在邊際節點上提供負載均衡和服務發現。在DCOS中可以部署於Public節點，為入口流量做路由負載。這種情況下可以將Public節點的IP通過A記錄與內部或外部DNS記錄綁定。

• Marathon-LB可用於內部負載均衡和服務發現，外部流量的入口路由負載可以使用硬體設備如F5，或者是雲負載如AWS的Elastic Load Balancer（ELB）。

• Marathon-LB只用於內部負載均衡和服務發現。

• 可以將內部LB和外部LB同時使用Marathon-LB，不同的服務根據需求開放給不同的Marathon-LB。

Mesos-DNS

Mesos-DNS為DC/OS集群中的應用提供了服務發現功能，可以讓DC/OS上運行的應用程序和服務通過域名系統（DNS）找到彼此。例如，由Marathon或Aurora啟動的應用程序可以分配名稱：search.marathon.mesos或log-aggregator.aurora.mesos，Mesos-DNS將這些名稱轉換為當前運行各個應用程序的主機上的IP地址和埠。要連接到DC/OS中的應用程序，必須要知道的應用的名稱，每次啟動連接時，DNS轉換都會將這些連接指向數據中心中正確的主機。

Mesos-DNS被設計為一個精簡的，無狀態的，易於部署和維護的服務。下圖描述了它的工作機理：

Mesos-DNS定期（默認30秒）查詢Master節點，從所有正在運行的框架中檢索所有正在運行的任務的狀態，並為這些任務生成DNS記錄（A和SRV記錄）。隨著任務在DC/OS集群上啟動，完成，失敗或重新啟動時，Mesos-DNS會同時更新DNS記錄以反映應用的最新狀態。

框架不需要直接與Mesos-DNS進行通信。在Agent節點上運行的應用程序和服務可以通過發出DNS查找請求或通過REST API發出HTTP請求來發現其所依賴的其他應用程序的IP地址和埠，Mesos-DNS會直接回復這些請求。如果Agent節點需要對DC/OS群集外部的主機名發出DNS請求，Mesos-DNS會直接查詢外部DNS伺服器。僅當DC/OS群集上的節點必須解析集群網路之外或Internet上其他位置的系統的主機名時，才需要外部DNS伺服器。

Mesos-DNS是簡單和無狀態的，它不需要一致性機制，持久存儲或日誌複製，因為應用所需的心跳，健康監控或生命周期管理等功能都已經由Master、Agent和框架所提供。Mesos-DNS可以通過使用像Marathon這樣的框架來實現容錯，可以監控應用程序運行狀況並在應用出現故障時重新啟動它。Mesos-DNS因故障重新啟動時，無需進一步協調它會從Master節點檢索最新的應用狀態，然後處理DNS請求。可以通過增加Master節點，即可提高可用性並為大規模集群中的DNS請求提供負載均衡。

當應用通過多個框架載入，而不僅僅是Marathon，Mesos-DNS是非常有用的。每個容器都有一個IP，類似Project Calico的解決方案。

總結

VIPs適合DC/OS集群內部服務之間的發現與負載均衡。

Marathon-LB既可以作為DC/OS集群外部入口，也可以作為內部服務的服務發現與負載均衡方案。

E-W(East-West) VIPs的服務發現與負載均衡功能是由DC/OS的兩個內部服務Minuteman（負載均衡）和Spartan（分布式DNS代理）協同處理實現的。在性能上，VIPs要優於Mesos-DNS。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！