天天看點
傳回

【運維趟坑回憶錄】vpc遷移 - 吃螃蟹之路探路正式上路

探路

前篇列出的都是緩兵之計, 大部分問題還是存在, 在前幾個月懵逼和飽受白名單問題煎熬後, 慢慢打起了vpc遷移的算盤.

這個遷移很大的一個問題就是, 如何将VPC和經典資源打通呢？

VPC經典互通的第一次嘗試

在16年底, 風控準備上第一版服務, 将服務放在了vpc内. 以此為契機嘗試打通vpc和經典的服務,但是這個時候阿裡雲vpc剛上沒多久, 基本沒有任何對這方面的支援.

第一次嘗試方案如下

  • 在vpc内建立了一個openvpn server把端口暴露給經典網絡
  • 在經典環境以一台空閑節點作為client保持和openvpn server的連接配接
  • vpn server給經典client下發vpc網段路由下一跳指向vpn server
  • 在vpn server上對vpn和經典網段分别進行SNAT
  • vpc路由器上将經典網段的10路由下一跳指向vpn server
  • 經典節點上對vpc和vpn網段SNAT

其他的經典節點由于路由不可控無法主動通路vpc, 經典client節點可以openvpn server的身份通路其他vpc所有節點.這樣經典client的節點相當于和vpc完全互通了.

而vpc内的節點則可以通過vpn client通路所有經典節點, 由于是在路由器上加的路由這個通路是對于vpc節點來說是無需配置, 無感覺的.

不過由于阿裡雲有一個神奇的100.64.0.0/10網段(RDS,DRDS,redis,部分SLB), 這個路由是無法控制的, 為了讓vpc能通路到阿裡雲的這些資源, 隻能不停在将各種不同的資源在經典的vpn client做DNAT.

DNAT規則大緻如下.

firewall { '100 snat for vpn':
  chain    => 'POSTROUTING',
  jump     => 'SNAT',
  proto    => 'all',
  source   => '192.168.0.0/24',
  table    => 'nat',
  tosource => '10.165.69.144',
}
firewall { '101 snat for vpn':
  chain    => 'POSTROUTING',
  jump     => 'SNAT',
  proto    => 'all',
  source   => '172.31.255.0/24',
  table    => 'nat',
  tosource => '10.165.69.144',
}
firewall { '102 dnat for drds xxx':
  chain    => 'PREROUTING',
  table    => 'nat',
  jump     => 'DNAT',
  source   => '!10.0.0.0/8',
  destination => '10.165.69.144',
  proto    => 'tcp',
  dport    => '3306',
  todest   => '100.98.69.136',
}
firewall { '103 dnat for rds xxx.mysql.rds.aliyuncs.com':
  chain    => 'PREROUTING',
  table    => 'nat',
  jump     => 'DNAT',
  source   => '!10.0.0.0/8',
  destination => '10.165.69.144',
  dport    => '3307',
  proto    => 'tcp',
  todest   => '100.114.46.162:3306',
}
firewall { '104 dnat for redis xxxx.m.cnbja.kvstore.aliyuncs.com':
  chain    => 'PREROUTING',
  table    => 'nat',
  jump     => 'DNAT',
  source   => '!10.0.0.0/8',
  destination => '10.165.69.144',
  proto    => 'tcp',
  dport    => '6379',
  todest   => '100.99.94.201',
}
firewall { '105 dnat for slb xxx':
  chain    => 'PREROUTING',
  table    => 'nat',
  jump     => 'DNAT',
  source   => '!10.0.0.0/8',
  destination => '10.165.69.144',
  proto    => 'tcp',
  dport    => '80',
  todest   => '100.114.31.148',
}

整個結構的簡單圖示:

【運維趟坑回憶錄】vpc遷移 - 吃螃蟹之路探路正式上路

這樣勉強達到了互通的要求, 但是問題也很明顯, vpn client和vpn server都是單點的. 期間分别準備好了備機以防止意外随時切換, 這種狀态跑了半年, 除了有時經典節點公網帶寬跑滿, 并未出現過其他問題, 更新過帶寬後也好了. iptables的轉發還是很給力的, 不過現在阿裡雲在互通方面做了很多支援,沒必要這樣做了.

正式上路

阿裡雲推出經典與vpc互聯支援後

阿裡雲文檔:

https://help.aliyun.com/document_detail/55051.html

主要支援了

ClassicLink

,

混訪混挂

單ECS遷移

, 既有的java應用也是在推出上述實際支援後開始的.

遷移問題

提前規劃

  • 遷移到vpc後, 自然不希望再和以前一樣看着經典ip一臉懵逼. 希望看到ip就能知道是哪個叢集裡的, 政策可以直接根據預先設定的網段來設定. 下面是之前規劃時整理的部分文檔(2017年4月寫的, 具體請以阿裡雲最新文檔為準)

限制:

  • 【運維趟坑回憶錄】vpc遷移 - 吃螃蟹之路探路正式上路

注意事項:

  • VPC 的交換機是一個 3 層交換機，不支援 2 層廣播群組播。
  • 每個交換機的第1個和最後3個 IP 位址為系統保留位址。以 192.168.1.0/24 為例，192.168.1.0、 192.168.1.253、 192.168.1.254 和 192.168.1.255 這些位址是系統保留位址。
  • 專有網絡内的 ECS 使用安全組防火牆進行三層網絡通路控制。

劃分原則

  • 每個分組對應至少一個或多個(可用區)交換機, 每個交換機綁定至少一個分組命名的安全組.
  • 每個分組對應至少一個分組命名的容器叢集.
  • 每個分組對應單獨的SNAT表或者SNAT IP POOL.
  • 每個分組之間預設完全隔離. 由安全組控制通路.通路
  • 每個分組保證至少2個可用區,核心業務三個可用區. 以可用區字母結尾, 例如 common-a 表示common分組, A可用區
  • 生産和測試vpc獨立, 完全隔離
    【運維趟坑回憶錄】vpc遷移 - 吃螃蟹之路探路正式上路

其實不太建議用

192.168.0.0/16

網段, 可用ip相對會少一些, 而且後續如果辦公網或者經典互聯容易出現問題.

路由問題

這裡需要注意2個問題

  • 預設情況路由表條目是有限制的, 預設是48, 如果後續容器化(阿裡雲為了打通容器網段, 會在路由表上自動添加路由條目, 容器網段下一跳指向對應主控端節點), 很容易達到限制配額. 可以手動控台申請配額, 或者工單申請.
  • 正常情況classiclink後, 經典網絡節點可以直接通路vpc節點, 但是如果vpc網段是

    192.168.0.0/16

     就比較特殊了, 需要手動在經典節點上加下路由. 腳本參考這裡 添加路由

新老服務互動

我們應用主要是dubbo + http方式來進行應用間的互相通路, 涉及數十個應用, 不會是一波進去, 就會存在一段時間需要vpc和經典互訪的情況.

dubbo服務
  • 利用classic将zk叢集和provider端鍊入vpc
  • vpc内建立一個zk叢集
  • consumer端先遷入, 同時注冊新老zk叢集, 因為後續使用的容器化, 直接在啟動entrypoint的腳本裡做一些處理即可, 應用無需改動. 
# add dubbo vpc registry
# find  /data/ -name "*.xml" -exec grep -Hn 'registry' {} \; | awk -F: '{print $1}' | xargs -i -t sed -i -r '/zookeeper.vpc.cluster/d' {}
# find  /data/ -name "*.xml" -exec grep -Hn 'registry' {} \; | awk -F: '{print $1}' | xargs -i -t sed -i -r '/registry/{h;s/dubbo:registry/& id="vpc"/;s/(address=")(.*)(")/\1${zookeeper.vpc.cluster}\3/;G}' {}
  • 後續provider遷入, 同理. 直至相關服務遷移完成後将主zk直接指向vpc的zk叢集, 老zk叢集下線.
http服務

這個比較簡單了, 因為我們内部服務也通過slb暴露, 這裡主要通過slb混挂來做.

  • vpc内起一個新的服務, 将相關節點挂入原有的經典内網slb.
  • 調整權重, 觀察服務正常逐漸替換老的節點即可.
  • 一般會在vpc内也再開一個vpc内網slb提供vpc内調用, 後續遷移完成後确認老的經典slb無流量後釋放即可.

公網slb其實同理. 不過由于在遷移vpc同時進行了容器化, 這裡稍微有些處理(下篇專門介紹容器化會說到)

阿裡雲相關資源調用

後續遷移過程中阿裡雲其實都已經提供了相當友善的支援, 在這之前我們都是使用的相當粗暴的走公網連結方式(很不推薦, 受公網帶寬限制, 而且有一定風險, 雖然traceroute測試下來公網路徑貌似都是經過的阿裡雲節點,但終究心裡沒底)

  • oss, ots, ons等等直接換成vpc的endpoint即可
  • drds,rds, redis稍微麻煩一點, 需要遷移vpc後選擇

    保留經典連結

     , 最多可以同時維持vpc,經典内網,公網三個連結位址, 而且經典位址保留時間可以工單延長. vpc内的應用直接使用vpc内網位址即可.

基本上在阿裡雲實際提供支援後, vpc和經典網絡這塊并沒有太多的障礙, 主要根據應用狀态, 逐個遷移觀察, 就是一些細心的活了. 更多踩到的坑還是在容器化中, 下篇繼續介紹vpc遷移同時容器化踩到的一些坑.

網絡協定 Dubbo NoSQL 關系型資料庫 應用服務中間件 Redis 網絡虛拟化 容器 perl rds ecs雲伺服器通過海量資料處理 url oss圖檔處理通路 ecs雲伺服器通過海量資料 ecs雲伺服器海量資料處理數字化 ecs雲伺服器海量資料處理企業
上一篇: 産品狗秋光的讀書筆記-《異類：不一樣的成功啟示錄》
下一篇: 基于Spark的機器學習實踐 (二) - 初識MLlib1 MLlib概述2 MLlib的資料結構3 MLlib與ml4 MLlib的應用場景Spark機器學習實踐系列

繼續閱讀