搞容器混搭搞出了線上 Redis 事故什么的
事情是這樣的, 現(xiàn)在有一個 redis 3.0 集群節(jié)點都是裸 redis 或 host 網(wǎng)絡(luò)模式部署的容器 redis (基本上跟裸 redis 差不多), 需要把它們替換成 macvlan 網(wǎng)絡(luò)模式的 redis 容器, 以顯得我們的 dockerized redis cluster 很上檔次.
這事情幾個月前也搞過一次毫無壓力.
然而這一次又搞, 就出岔子了. (這劇本不對啊摔)
于是開始加了兩個 macvlan 的容器到上述 redis 集群作為從節(jié)點, 打算稍候 failover 替換掉主, 過了十分鐘左右群里炸毛, 說數(shù)據(jù)都取不到, 或者格式不對...
上線一查, 發(fā)現(xiàn)正在加從節(jié)點的這個集群跟另一個集群的節(jié)點混到一起去了.
這里吐槽一下 redis 集群的協(xié)議, 兩個正常服務(wù)的集群可以直接通過一個 cluster meet 合并成一個集群, 然后槽位分布亂了...
首先當(dāng)然是緊急恢復(fù)線上業(yè)務(wù), 先拉一個新集群出來再說 (所幸這個集群的數(shù)據(jù)不需要持久化).
結(jié)果, 新集群剛弄出來, 又被合進(jìn)了上面那個集群. (這時我滿腦子都是某個科教片里兩個星系合并的一段視頻, 滿天都在炸! (論腦洞
然后 cluster nodes 看了一下, 發(fā)現(xiàn)集群里有幾個節(jié)點地址變成了 172.17.x.x, 這應(yīng)該是 docker 的內(nèi)部網(wǎng)段地址, 所以反應(yīng)過來, 可能是 docker 網(wǎng)絡(luò)配置問題, 將握手流量發(fā)給了錯誤的節(jié)點, 然后那些節(jié)點被并了進(jìn)來.
這時候創(chuàng)建一個新網(wǎng)段有點來不及了 (還打了個電話給已經(jīng)請假回家的 @小六哇啦啦 老師...) 換了個思路, 把新 redis 換個端口部署, 再組個集群, 觀察了一會兒, 這方法起作用了 -.-!!
恢復(fù)了被炸得雞飛狗跳的線上業(yè)務(wù)之后, 就開始排查問題了.
線索還是之前 cluster nodes 看到的那個 172.17.x.x 網(wǎng)段, 測試確認(rèn)了一下, 從 docker 容器內(nèi)連宿主機, 宿主機 accept 得到的會是 172.17.x.x 這個地址. 而容器內(nèi)路由表是這樣的
確實如果宿主機的 IP 是 10.100.1.100 那么流量走的是 eth0 也就是 172.17.x.x 網(wǎng)卡. (10.222.0.0/16 是容器 macvlan 地址)
之后就明白了, 172.17.x.x 這樣的網(wǎng)卡地址在不同物理機上是可能相同的. 也就是說, 遭遇的問題可能是如下過程所致
- 四個 redis #a #b #c #d
- #a #b 是兩個 host 網(wǎng)絡(luò)的 redis, 在同一個集群中, #d 是 macvlan 部署的 redis, 在另一個集群中
- #c 是一個空閑的 redis, 它與 #d 恰好有相同的 eth0 地址
- #c 通過 eth0 向 #a 發(fā)送了一個 handshake
- #a 確認(rèn), 這時, 它認(rèn)為 #c 的地址是 172.17.0.55
- #a 將新節(jié)點地址廣播給 #b
- #b 向 172.17.0.55 發(fā)送一個握手請求, 然而, 此地址在它所在機器上對應(yīng)的是 #d, 之后兩個集群就混一起去了
這也解釋了為啥幾個月之前這么搞的時候沒出問題, 應(yīng)該是那時候運氣好沒有相同地址的容器; 同時也解釋了為啥不是每個純 macvlan 模式的 redis 集群都中槍.
后來在測試機房找了兩個恰好相同網(wǎng)卡的容器, 按上述思路搭了集群試了試, 果然重現(xiàn)了.
解決方案
- 因噎廢食 : 以后別這么混搭玩了
- 繞過 : 端口號不一樣法
- 改默認(rèn)路由 : 默認(rèn)就走 vlan 網(wǎng)卡, 不過這樣的話不能訪問外網(wǎng), 對 redis 而言沒問題, 但其他業(yè)務(wù)可能就不行了
- 加路由 : 其實可以通過在容器內(nèi)加一條路由 10.100.0.0/16 走 vlan 這樣宿主機 accept 到的地址就會是機房***的 vlan 網(wǎng)卡地址了, 這個方案 @CMGS 正在評估中
EOF
