大型資料中心雲端平台網路知識與實踐

叶一力 twt企业IT社区
【導讀】本文介紹了雲端運算中網路的一些重要知識和原理,以及結合實際業務分享產業雲的一些架構設計。
【作者】一力搜索,某銀行分散式資料庫架構師,重點負責行內分散式資料庫領域及私有雲。

最簡單的總結
SDN主流選擇了OverLay。 虛擬集群的規模(非實體機所能比擬) 使得Vxlan的組播傳播( 虛擬機構成的集群包含的MAC 地址數量往往多一兩個數量級MAC地址表)對網絡設備性能要求巨大(你不可能每 個交換器都買核心交換器一樣的配置吧)。 Overlay透過隧道技術(VxLAN或GRE)和控制平面可以減少叢集中MAC位址表和ARP請求( H3C VXLAN解決方案基於SDN架構,透過引入全網的SDN Controller來實現VXLAN的管理和維護,使得VTEP之間 的資訊可以透過Controller來進行反射。這樣,VTEP的MAC位址表映射關係不再透過組播向全網其他VTEP傳達,而是統一上報給控制器,由控制器統一下發給需要接受此訊息的 其他VTEP,由具體的VTEP執行轉發機), VxLan中Vlan內部只走2層網關,只有VxLan之間(不同租戶,雲端主機和裸金屬之間)才需要走3層網關。 進而有效降低二層核心網路設備壓力。

常見網路術語
普通的VLAN數量只有4096個,無法滿足大規模雲端運算IDC的需求,而IDC為何需求那麼多VLAN呢,因為目前大部分IDC內部結構主要分為兩種L2,L3。

L2( 二層網關 ) :位於同一網段的終端用戶通信,L2網關收到用戶報文後,根據報文中包含的目的MAC類型 進行轉發。

L2網關主要解決的就是同一VNI下的VM之間的互訪 。

L3(三層閘道):用於非同一網段的終端用戶通訊或VXLAN和非VXLAN用戶間的通訊。

L3閘道解決的是不同VNI(VXLAN Network Identifier)以及VXLAN和非VXLAN之間的互訪

VTEP(VXLAN Tunnel Endpoints,VXLAN隧道端點) 為VXLAN隧道的端點,封裝在NVE中,用於VXLAN封包的封裝和解封裝。 VTEP與實體網路相連,分配的位址為實體網路IP位址。 VXLAN封包中來源IP位址為本節點的VTEP位址,VXLAN封包中目的IP位址為對端節點的VTEP位址,一對VTEP位址就對應一個VXLAN隧道。

L2架構裡面,所有的伺服器都在一個大的區域網路裡面,TOR透明L2,不同交換器上的伺服器互通靠MAC位址,通訊隔離和廣播隔離靠的vlan,網關在內網核心上。 而L3結構是從TOR層級就開始用協定進行互聯,網關在TOR上,不同交換器之間的互通靠IP位址。

ToR(Top of Rack):存取方式就是在伺服器機櫃的最上方安裝接入交換器。

EoR(End of Row):接取交換器集中安裝在一列機櫃端部的機櫃內,透過水平纜線以永久連結方式連接設備櫃內的主機/伺服器/小型機設備。 EoR 對設備機櫃需要敷設大量的水平纜線連接到交換器。

對比:

EOR佈線方式的缺點:從伺服器機櫃到網路機櫃的銅纜多(約有20-40根銅纜),且距離網路機櫃越遠的伺服器機櫃的銅纜,在機房中的佈線距離越長,由 此導致線纜管理維護工作量大、靈活性差。

TOR佈線的缺點:每個伺服器機櫃受電源輸出功率限制,可部署的伺服器數量有限,由此導致機櫃內交換器的存取連接埠使用率不足。 在幾個伺服器機櫃間共用1-2台接取交換機,可解決交換器連接埠使用率不足的問題,但這種方式增加了線纜管理工作量。

從網路設計考慮,TOR佈線方式的每台接入交換機上的VLAN量不會很多,在網路規劃的時候也要盡量避免使一個VLAN通過匯聚交換機跨多台接入交換機,因此採用TOR佈線方式的 在網路拓撲中,每個VLAN的範圍不會太大,包含的連接埠數量也不會太多。 但對於EOR佈線方式來說,接取交換器的連接埠密度高,在網路路徑最初設計時,就可能存在包含較多連接埠數的VLAN。

TOR方式的接入交換器數量多,EOR方式的接入交換器數量少,所以TOR方式的網路設備管理維護工作量大。

隨著用戶資料業務需求的激增,資料中心機房伺服器密度越來越高,虛擬化和雲端運算等新技術趨勢日益流行,使得伺服器對應的網路連接埠大大增加,並且增加了管理的複雜性,另外 乙太網路(LAN)與光纖儲存區域網路(SAN)的融合也越來越常見,這必然要求一種新的網路拓撲結構與之相對應。 在雲端運算的大潮下,這種分散式架構的業務擴展性極強,要求的伺服器數量也越來越多。 例如新的Apache Hadoop 0.23支援6000~10000台伺服器在一個叢集內,海量的伺服器數量要求充分利用資料中心機櫃空間的同時,海量的業務資料也需要更快更直接的高效能連結把資料傳送到 網路核心。 在這樣的趨勢下,顯然ToR更加適用,在業務迅速擴展的壓力下,ToR的方式可以更好的實現網絡的更快速擴展。

一 . SDN
在SDN解決方案中overlay與underlay是最常見的二個網路術語。

UnderLay指的是實體網絡,它由實體設備和實體連結組成。 常見的實體設備有交換器、路由器、防火牆、負載平衡、入侵偵測、行為管理等,這些設備透過特定的連結連接起來形成了一個傳統的實體網絡,這樣的實體網絡,我們稱之為UnderLay網路。

實作 SDN的技術主要有 overlay , OpenFlow ,和思科的 onePK 。 Overlay已成主流,該類方案主要思想可被歸納為解耦,獨立,控制三個面向。

OverLay其實就是一種隧道技術 ,VXLAN,NVGRE及STT (都是OverLay實現方式之一) 是典型的三種隧道技術, 它們都是透過隧道技術實現大二層網路。 將原生態的二層資料幀報文進行封裝後再透過隧道進行傳輸。 總之,透過OverLay技術,我們在對實體網路不做任何改造的情況下,透過隧道技術在現有的實體網路上創建了一個或多個邏輯網路即虛擬網絡,有效解決了實體資料中心,尤其是 雲端資料中心存在的諸多問題,實現了資料中心的自動化和智慧化。

與UnderLay網路相比,OverLay實現了控制與轉發的分離,這是SDN的核心理念 。

Overlay 技術與 SDN 可以說天生就是適合互相結合的技術組合。 Overlay 網路虛擬機器實體位置無關特性就需要有一個強而有力的集中控制技術進行虛擬機器的管理與控制。 而 SDN 技術恰好可以完美的做到這一點。

二 . OverLay 解決哪些痛點
Overlay由於其簡單、一致的解決問題方法,加上重新定義的網路可以進行軟體定義,已成為資料中心網路最炙手可熱的技術方案。 然而,它並不是完全由軟體定義的網絡,Overlay網絡解決方案必定是一種軟硬結合的方案,無論是從接入層VTEP混合組網的組網要求、組播或SDN控制層協議 的支持,還是VXLAN網路與傳統網路的互通來看,都需要硬體的積極配合與參與,必須建構在堅實且先進的實體網路架構基礎上。

考慮到伺服器存取的可以是虛擬交換機,也可以是實體交換機,因此有三種不同的建置模式:

2.1 OverLay类型

2.2 Overlay 网络主要解决的问题

三 . 為什麼需要 Vxlan
在雲端運算IDC裡,要求伺服器做到虛擬化,原來這個伺服器掛在TOR A上,我可以隨意把它遷移到TOR B上,而不需要改變IP位址,這個優點就是L2網路的特長,因為 我這個虛擬伺服器和外界(網關之外)通訊還靠L3,但是我網關內部互訪是走L2的,這個在L3裡是無法做到的。 因為L3裡每個IP都是唯一的,位址也是固定位置的,除非你整網段物理搬遷。 因此如何在L3網路裡傳輸L2資料呢,這就是overlay技術。

因此VXLAN(Virtual eXtensible LAN可擴充虛擬區域網路)誕生了,基於IP網路之上,採用的是MAC in UDP技術,原本OSI7層模型裡就是一層疊一層的,這種和GRE/IPSEC等tunnel技術是 不是很像,這種封裝技術對中間網路沒有特殊要求,只要能辨識IP封包即可傳送。

好了,解釋清楚了,那麼現在總結為何需要Vxlan:

虛擬機器規模受到網路規格的限制,大L2網路裡,封包透過查詢MAC位址轉發, MAC表容量限制了虛擬機器的數量。

網路隔離的限制,普通的vlan和VPN配置無法滿足動態網路調整的需求,同時配置複雜

虛擬器搬遷受到限制,虛擬機啟動後假如在業務不中斷基礎上將該虛擬機遷移到另外一台實體機上去,需要保持虛擬機的IP位址和MAC位址等參數保持不變,這就要求業務 網路是一個二層的網路。

3.1 報文的封裝與解封裝
VXLAN的核心在於承載於實體網路上的隧道技術,這意味著要對封包進行封裝和解封裝,因此需要硬體來加速處理。

在VXLAN網路中,用於建立VXLAN隧道的端點設備稱為VTEP(VXLAN Tunneling End Point,VXLAN隧道終結點 ,起到網關的作用 ), 封裝和解封裝在VTEP節點上進行 。

在雲端資料中心,部分業務是不適合進行虛擬化的(如小機伺服器,高效能資料庫伺服器),這些伺服器會直接與實體交換器互聯, 而他們又必須與對應租用戶/業務的VXLAN網路互通,此 時必須要求與其互聯的硬體交換器也能支援VXLAN協議,以接取VXLAN網路。

3.2 組播協定傳播
簡單總結,vxlan用組播協定傳播,每個VTEP都需要清楚來源和目的MAC,新增MAC位址需要組播通知一實例下所有VTEP。 另,本地VTEP 找不到目的MAC處於哪一個遠端VTEP時,也需要組播封包查找目的MAC主機所屬遠端VTEP。 租戶很多時,組播條數指數增加,對實體網路承載組播處理能力有較大要求。 引入SDN Controller來實現VXLAN的管理和維護,VTEP的MAC位址表映射關係不再透過組播向全網其他VTEP傳達,而是統一上報給控制器,由控制器統一下發給需要接受此訊息的 其他VTEP,由具體的VTEP執行轉送機制。

VXLAN網路的MAC表與隧道終端的綁定關係要用組播協定傳播,而大規格組播協定離不開實體網路設備的支援。

依照VXLAN的標準, 每個VTEP都需要了解其存取的終端MAC位址,同時也需要知道整網(該VXLAN實例中)其他VTEP下所有的終端MAC位址。 只有這樣,在本地的VTEP收到報文後需要轉發時,才能根據目的MAC查詢到需要送到遠端的目的VTEP那裡 。

依照IETF中對VXLAN網路的定義,負責在網路中傳播MAC位址和VTEP對應關係的機制,正是依託於實體網路中的組播協定。 VTEP將本地的MAC位址表利用組播協定在整個組播中傳播,從而使得整網中所有組播成員,也就是其他VTEP都知道本地的MAC位址表。 當VTEP下的終端存取情況有所更改,例如新增了MAC位址或減少了MAC位址,也需要利用組播協定通知同一個實例下的所有VTEP。 另外,當本地VTEP找不到目的MAC處於哪一個遠端VTEP時,也需要發送組播封包來尋找目的MAC主機所屬的遠端VTEP。

實際組網中,VXLAN利用了實體網路的組播群組,在建立好的組播群組中加入VXLAN中所有VTEP成員,傳遞VTEP變更資訊。 在多用戶多業務情況下,組播群組要求與VXLAN數量息息相關。 由於VXLAN網路規模的不斷拓展 (最大可達16M個VXLAN網路),所需的組播條目數會不斷增加,這實際上對於實體網路承載組播處理能力和規格提出了要求。

由於標準VXLAN架構下使用組播協議,對實體網路組播數規格要求較大,因此H3C VXLAN解決方案基於SDN架構, 透過引入全網的SDN Controller來實現VXLAN的管理和維護,使得VTEP之間的 資訊可以透過Controller來進行反射。 這樣, VTEP的MAC位址表映射關係不再透過群播向全網其他VTEP傳達,而是統一上報給控制器,由控制器統一下發給需要接受此訊息的其他VTEP, 由具體的VTEP執行轉發 機制。

在SDN架構下,硬體形態的VTEP需要能夠支援集中控制器下發的業務控制訊息,同時基於Openflow進行流程表轉送。 而傳統硬體交換器不能支援上述特性,必須由新硬體設備來執行和完成的。

3.3 VXLAN網路互通
在傳統L2網路中,封包跨VLAN轉發,需要藉助三層設備來完成不同VLAN之間的互通問題。 VXLAN網路與傳統網路、以及VXLAN網路的互通,必須有網路設備的支援。

VXLAN網路框架中定義了兩種網關單元。

VXLAN三層閘道。 用於終結VXLAN網絡,將VXLAN封包轉換成傳統三層封包送至IP網絡,適用於VXLAN網路內伺服器與遠端終端之間的三層互訪;同時也用作不同VXLAN網路互通(可 理解為不同VPC) 。 當伺服器存取外部網路時,VXLAN三層閘道剝離對應VXLAN封包封裝,送入IP網路;當外部終端存取VXLAN內的伺服器時,VXLAN依據目的IP位址確定所屬VXLAN及所屬的VTEP,加上對應的 VXLAN封包頭封裝進入VXLAN網路。 VXLAN之間的互訪流量與此類似,VXLAN閘道剝離VXLAN封包頭,並基於目的IP位址確定所屬VXLAN及所屬的VTEP,重新封裝後送入另外的VXLAN網路。

VXLAN二層閘道。 用於終結VXLAN網絡,將VXLAN封包轉換成對應的傳統二層網路送到傳統乙太網絡,適用於VXLAN網路內伺服器與遠端終端或遠端伺服器的二層互聯。 如在不同網路中做虛擬機器遷移時,當業務需要傳統網路中伺服器與VXLAN網路中伺服器在同一個二層中,此時需要使用VXLAN二層網關打通VXLAN網路和二層網路。 如圖7所示,VXLAN 10網路中的伺服器要和IP網路中VLAN100的業務二層互通,此時就需要透過VXLAN的二層閘道進行互聯。 VXLAN10的封包進入IP網路的流量,剝掉VXLAN的封包頭,依照VXLAN的標籤查詢對應的VLAN網路(此處對應的是VLAN100),並據此在二層封包中加入VLAN的802.1Q 封包送入IP網路;相反VLAN100的業務流量進入VXLAN也需要依VLAN獲知對應的VXLAN網路編號,依目的MAC獲知遠端VTEP的IP位址,基於上述資訊進行VXLAN封裝後送入對應的VXLAN網路。

可見,無論是二層或三層網關,均涉及到查表轉送、VXLAN封包的解封裝及封裝操作。 從轉送效率和執行效能來看,都只能在實體網路設備上實現,而且傳統設備無法支持,必須透過新的硬體形式來實現。

如何做好 openGauss 企業級部署?

如何做好 openGauss 企業級部署?
原始 twt社區 twt企業IT社區 2023-12-29 07:35 發表於海南
圖片
【摘要】openGauss資料庫作為開源資料庫的後起之秀,這兩年蓬勃發展,關於其細緻的安裝教程,網路上並不缺少,但其作為新的資料庫,如何做好企業及部署,這是值得探討的方向。 本文結合商業資料庫應用與部署的經驗,討論openGauss資料庫企業級應用需求下需要考慮的方方面面,具有獨特的參考價值。
【作者】孔再華,具有豐富的資料庫環境問題診斷與效能調優的經驗。 在資料庫同城雙活,集群,多分區,分佈式等項目實施上具有豐富的經驗。 現任職於某股份制銀行科技部,工作致力於資料庫同城雙活架構建設,資料庫分散式架構建置與資料庫智慧維運(AIOps)方向。 對於如何將AI技術運用在維運領域具有濃厚的興趣和創新熱情。

openGauss資料庫作為開源資料庫的後起之秀,這兩年開源社群蓬勃發展,越來越多的公司和企業加入openGauss開源社群。 作為純國產開源的關係型資料庫,目前部分銀行已經嘗試在生產應用openGauss資料庫,同時也有許多合作夥伴在openGauss核心的基礎上推出各自的商業版本。

openGauss資料庫至今為止基本上保持三月一次發版的節奏。 每次發版都會發現內容非常多,不僅包含大功能的新增和改進,同時也有非常多的問題被修復。 可以說openGauss開源社群的投入,並不遜色於傳統的大型商業資料庫公司。 國內幾家合作夥伴的加入與貢獻,也讓openGauss資料庫生態越來越好,也為企業在生產使用openGauss資料庫帶來更大的信心。

作為新的資料庫,如何做好企業及部署,這是值得探討的地方。 這篇文章並不是一個細緻的安裝教程,網路上也不缺乏該類教程,而是結合商業資料庫應用和部署的經驗,討論下openGauss資料庫企業級應用需求下需要考慮的方方面面。

資料庫結構定義設計
openGauss作為集中式的單機資料庫,這裡的架構設計主要是討論高可用怎麼做,同城和異地容災怎麼做。

本地高可用
傳統的資料庫本地高可用有兩種比較流行的方式:集中式儲存方式和資料庫複製方式。 Db2和Oracle等商業資料庫的部署大多都是採用集中式儲存的模式。 而MySQL資料庫基本上就是透過資料庫複製的模式來實現高可用。

集中式儲存
集中式儲存方案是目前企業級部署中應用最廣泛且最成熟的方案。 資料庫的資料部署在儲存上,上層透過系統的HA工具監控和切換。 然而這種方式也有缺點。 首先是外置儲存的效能和內建SSD碟的效能差異在資料庫應用場景對比還是比較明顯的。 其次是磁碟資料的損壞需要透過資料庫復原來修復,相對恢復時間較長。 最後從部署成本來說,集中式儲存方案部署較重,需要儲存佈線等。

資料庫複製
資料庫複製方案是透過資料庫日誌的實體或邏輯同步,在備機即時重做主機的修改,從而確保主備資料庫的資料一致性。 這也是一個非常成熟的方案。 Db2和Oracle等商業資料庫都有基於資料庫日誌物理同步的功能。 MySQL的日誌邏輯複製也應用非常廣泛。 這種方案下資料庫主機上的儲存採用內建磁碟,主備的資料是完全隔離的,更好的利用了內建磁碟的效能和做到了儲存上的隔離。

openGauss資料庫也支援資料庫日誌的實體複製和邏輯複製。 邏輯複製存在一個比較重大的缺點,就是對於大交易的資料回放效能不好。 因此在openGauss資料庫的高可用設計中,資料庫日誌物理同步是目前最好的方案。

官方的架構圖也是建議使用這種方式。 openGauss資料庫提供了om工具來幫助部署和管理openGauss資料庫的主備叢集節點。 openGauss資料庫的實體複製支援一主多備和級聯備等功能,未來也會加入延時複製功能。 openGauss的備機是支援唯讀操作的,可以實現讀寫分離,減少主函式庫的讀負載。

建議本地高可用就透過資料庫物理同步來實現。 建議開啟備機可讀,設定wal_level為hot_standby。 為了保障資料一致性,synchronous_commit建議修改為remote_write或remote_receive。 如果只有一主一從的情況下,建議設定most_available_sync為on。 最後透過第三方的高可用叢集軟體來監視openGauss的主從狀態,實現故障自動切換等高可用情境。

客戶端存取方式
openGauss資料庫主從架構下,客戶端如何連接到主資料庫? 又怎麼做讀寫分離? 這時候就需要討論下客戶端連接資料庫的幾種方式:VIP,DNS和主機清單。 因為openGauss資料庫的jdbc驅動裡支援設定多個主機,並提供參數設定只連主節點還是只連備節點,這也應對了讀寫分離的需求。

VIP
傳統的VIP模式只能支援應用程式連接到主節點上,從節點的讀取請求是不太好設定的。 增加讀取VIP的管理對於高可用軟體來說就太複雜了。 VIP管理還有一個限制是必須屬於同一網段。 對於同城雙中心不能採用相同網段的情況下,VIP漂移就不能實現。

DNS
DNS也具備高可用性,但只能偵測到機器IP是否存在,無法偵測openGauss的服務,所以採用DNS的高可用相對來說不太適合資料庫來使用。

主機列表
例如下面這個範例就是只連主庫的客戶端設定:

url=jdbc:postgresql://:26000,:26000/?connectTimeout=5&targetServerType=master&tcpKeepAlive=true

我比較偏向採用主機清單的方式,透過設定客戶端參數,實現自動主庫發現,負載平衡,只讀從庫等各類應用場景需求。 這種方式也避免了VIP,DNS在不同架構下的管理複雜性,相對更通用一些。 缺點是增加了一點客戶端資料來源配置的複雜性。

同城容災
資料庫級的同城容災可能會分成不同的等級來實現。 金融業的同城資料中心一般都要求具備全量承載資料和業務的能力。 資料庫實現同城容災最主要目標是最小化RPO和RTO指標,在此基礎上可能還會有同城災備資料庫的唯讀存取等需求。 同城容災的實現方式也有兩種主流模式:儲存複製和資料庫複製。 優缺點和本地高可用差不多。 但如果本地openGauss採用了內建磁碟部署,那麼也就不支援做儲存複製的容災模式了。 所以建議openGauss資料庫還是採用資料庫複製的方式。 注意在設定synchronous_standby_names的時候要確保同城至少有一個節點處於資料同步狀態。

這裡稍微討論下同城容災的幾個定位:

1.同城是否需要保障RPO=0?

金融業的大部分需要做同城容災的應用都要求RPO=0,不能容忍同城切換遺失資料。 因此在設計synchronous_standby_names的時候需要加上同城備機並設定成同步模式。 然而雙中心間的網路穩定性顯然比同中心要差很多,為了避免設定了強同步後,雙中心網路抖動可能會影響主機效能,可以考慮設定most_available_sync參數為ON,遺失備機的情況下主機 可以斷開備機並恢復工作。

2.同城資料庫是否需要只讀存取?

資料庫的備機提供唯讀存取的能力,包括同城的資料庫備機。 那麼是否真的需要去啟用這個功能呢? 從前端業務的性能考慮,顯然同機房訪問要比跨機房訪問要更快一些。 而從後端資料庫的處理能力來說,需要只讀能力擴展的需求,都是為了滿足減輕主庫的運作壓力,也要求應用程式能夠配置單獨的唯讀資料來源,從應用層就解決好讀 寫分離。 在這些場景需求裡,顯然本地的備機只讀訪問就可以解決這些問題,所以大概率是不需要升級到同城只讀訪問的性能擴展需求的。 只有一種情況下需要同城只讀訪問,那就是為了架構的便利性,同城切換的便利性等需求。 這種情況並不是以擴展效能為目的,而是以技術架構方案的整體性設計需求。

3.同城是否需要自動切換?

這個問題一直是討論的比較多的地方。 保守一點的想法是同城切換都是交給人工來決策的。 激進一點的想法是同城都保障不丟資料庫,當然也可以自動切換,交給HA監控並自動化切換修復多好。 所以面對不同的選擇,這裡對於同城的定位就不一樣,所涉及的HA架構設計也很不一樣。 個人認為除非同城雙中心定位完全無主次之分,否則大部分應用還是偏向於運行在主機房,這種情況下,同城切換適合交給人為決策,自動化平台快速實現。

異地容災
異地容災也需要分不同的資料保護類型。 可能最關鍵的應用也就是盡可能減少RPO和RTO。 這種類型的關鍵應用也是建議透過資料庫主從複製的方式來實現,只是異地的資料庫節點通常都是設定為非同步模式。

openGauss資料庫支援級聯備,也就是從一主多從的某個從庫上,配置一個級聯備機,指向異地容災的資料庫從庫。 這也是比較推薦的方式,減少主庫的壓力。

使用者規劃設計
這裡主要討論下安裝部署裡的作業系統用戶,資料庫使用者等規劃設計。

系統用戶
作業系統使用者主要是安裝openGauss的使用者和群組,以及需要使用gsql客戶端存取openGauss資料庫的作業系統使用者。 例如華為的openGauss資料庫預設採用omm用戶和dbgrp用戶群組,這在華為的高斯分散式產品裡都是這個設計的。 我們使用openGauss的時候也延續了這個習慣。

超級用戶
omm作業系統使用者俱有openGauss資料庫程式的存取權限,能執行gsql、gs_ctl等工具。 而這些工具的權限一般是700,也就是說只有omm用戶能使用。 而通常omm用戶訪問本地的openGauss是透過socket,可以使用超級用戶,還可以免密,因此這個用戶完全是交給系統管理員的,不適合交給用戶使用。

應用程式用戶
那如果應用程式使用者需要使用gsql等工具怎麼辦? 這種情況建議設計一個系統使用者appuser,並為它安裝一個單獨的gsql等工具客戶端,透過IO連接資料庫。

資料庫用戶
資料庫使用者也應該分為幾種類型:超級管理員、監控管理員、資料庫管理員和普通資料庫使用者。

超管理員
一開始initdb的初始用戶就是超級管理員用戶,具有sysadmin的權限。 這個使用者通常不會交給應用程式來使用,甚至不應該當作超級管理員來使用。 這個使用者只能是作為能夠登入這個作業系統上應急的免機密超級使用者。

所以為了管理openGauss資料庫,我們還需要建立一個單獨的管理員使用者俱備sysadmin角色權限。 例如設計一個gsadmin用戶,在維運工具平台透過這個用戶遠端管理所有的openGauss資料庫。

create user gsadmin with sysadmin password ‘xxxxxxxx’

還有一種用戶是遠端備份用戶,建議建立單獨的用戶並sysadmin角色權限。

監控管理員
openGauss資料庫從2.0.0版本開始提供了monadmin角色。 這個角色權限能夠存取所有的系統視圖。 因此對於監控用戶,建議配置這個角色即可。

create user monadmin with monadmin password ‘xxxxxxxx’
資料庫管理員
openGauss的資料庫是相互隔離的。 對於每一個獨立的資料庫,可以設定一個資料庫管理員角色的用戶,給予全庫的管理權限。

grant all privileges on database to

這種用戶通常也是作為應用程式來連結的用戶,具備全庫的物件管理能力,也具備資料修改查詢能力。 這是很常見的用法, 很少在應用資料來源設定連線使用者的時候還繼續做細緻的權限分離。 當然資料庫權限管理是具備相關能力的。

普通資料庫用戶
除了本應用系統使用的資料庫管理員用戶,可能還有類似跨系統存取的特殊需求情況。 例如抽取資料的用戶,只讀訪問的用戶等。 這些使用者建議建立單獨的最小授權使用者。

白名單
在openGauss資料庫的目錄下,設計了pg_hba.conf設定文件,用來定義使用者存取資料庫的方式,也可以稱為白名單管理。 定義了在什麼訪問類型下,訪問哪個資料庫,是哪個用戶,從哪裡來訪問,採用何種驗證方式。 這些組合可以實現很複雜的白名單過濾規則。 這種可以過濾IP的用戶存取控制有點像mysql,但又完全不一樣。 openGauss裡的資料庫使用者名稱對應的就是一個使用者角色,不像mysql,如果使用者名稱裡的IP不一樣,其實算是不同的使用者。

不過從金融業的實務來看,資料庫伺服器和應用伺服器等在隔離的網路區內,主機間的存取控制透過網路來管理,基本上不需要底層資料庫來實現複雜的管控。 為了管理方便,不如全部放開資料庫層級的ip管控。 下面這個範例使用gs_guc工具來設定整個叢集所有的白名單:

gs_guc reload -N all -I all -h “host all all 0.0.0.0/0 sha256”

翻譯過來就是任何IP基於host請求過來的所有用戶存取所有資料庫都採用sha256加密演算法驗證用戶。

檔案系統設計
openGauss資料庫建議配置至少兩個獨立的檔案系統。 一個用來放資料庫,一個用來放資料庫運行中產生的歸檔日誌,診斷日誌等。

資料庫
資料庫存放的路徑建議放在單獨的檔案系統上。 部分重要的業務系統也建議將線上日誌pg_xlog放在單獨的檔案系統上,與資料data分開。 然而從實際情況來看,data和xlog採用不同的檔案系統,除非底層的磁碟也是獨立的,效能是沒有什麼差別的。 因此暫時建議採用一個就可以了。

診斷日誌
資料庫運行中產生的診斷日誌,審計日誌,歸檔日誌,core文件等,都是不影響資料庫運行的,但是又持續不斷的產生的。 因此需要單獨規劃一個檔案系統來存放,同時做好這些日誌的清理策略。 這個文件系統也可以用來規劃存放腳本文件,備份文件,跑批文件等臨時文件。

例如將歸檔日誌路徑、稽核日誌路徑、core檔案路徑和診斷日誌路徑都設定到這個檔案系統下面。

gs_guc set -c “archive_command = ‘cp %p /gausslog/archive/%f'”
gs_guc set -c “audit_directory=’/gausslog/log/omm/pg_audit'”
gs_guc set -c “bbox_dump_path=’/gausslog/corefile'”
gs_guc set -c “log_directory=’/gausslog/log/omm/pg_log'”

其他維運設計
規劃好了資料庫安裝,下一步就是設計相關維運需求方案。

性能參數設定
安裝完成之後最先需要的是根據業務負載需求設定相關參數。 這些參數細節比較多,需要好好閱讀相關資料再做選擇。 其中max_process_memory和shared_buffers是比較關鍵的記憶體參數,建議依照作業系統記憶體總量(資料庫獨佔資源)的70%和50%來設定。

增量檢查點和雙寫開關應該要打開。 這是openGauss相對於postgresql比較大的改進機制,解決了全量檢查點的效能瓶頸問題。 enable_opfusion開關也建議打開,對於高並發小事務的競爭會有改善。

gs_guc set -c “cstore_buffers = 128MB”
gs_guc set -c “enable_alarm = off”
gs_guc set -c “enable_delta_store = on”
gs_guc set -c “enable_double_write = on”
gs_guc set -c “enable_incremental_checkpoint = on”
gs_guc set -c “enable_wdr_snapshot = off”
gs_guc set -c “enable_xlog_prune = on”
gs_guc set -c “log_min_duration_statement = 1s”
gs_guc set -c “maintenance_work_mem=1GB”
gs_guc set -c “max_connections = 2000”
gs_guc set -c “max_files_per_process = 10000”
gs_guc set -c “max_prepared_transactions = 2000”
gs_guc set -c “session_timeout = 0”
gs_guc set -c “shared_buffers = 2GB”
gs_guc set -c “temp_buffers = 128MB”
gs_guc set -c “update_lockwait_timeout = 1min”
gs_guc set -c “wal_buffers = 64MB”
gs_guc set -c “wdr_snapshot_interval = 10min”
gs_guc set -c “work_mem = 512MB”
gs_guc set -c “log_temp_files = 100MB”
gs_guc set -c “enable_mergejoin = ON”
gs_guc set -c “enable_nestloop = ON”
gs_guc set -c “advance_xlog_file_num = 10”
gs_guc set -c “pagewriter_sleep = 1000ms”
gs_guc set -c “xloginsert_locks = 50”
gs_guc set -c “lockwait_timeout = 1min”
gs_guc set -c “enable_opfusion = off”
gs_guc set -c “max_process_memory=3GB”

自動管理
為了降低DBA的維運工作量,使用openGauss的流程要充分利用好資料庫的自動管理機制。 尤其是跟性能動態調整相關的機制。

自動統計資訊收集分析
openGauss資料庫內部的執行計劃有兩種選擇方式,基於規則和基於代價。 基於代價的這種方式依賴資料庫的統計資訊。 資料庫的統計資訊是由analyze指令收集的。 除了人為發出analyze指令,openGauss內部也提供了自動analyze的功能。 建議打開autoanalyze和autovacuum的開關。

自動清理
openGauss的儲存引擎還有一個比較特殊的地方,就是update和delete都會保留原元組,作為MVCC的基石。 這種機制會不停產生死元組,並且一直佔據表內的空間。 這種情況下需要vacuum指令來回收這些空間,後續的資料才能使用。 openGauss提供了autovacuum機制,能夠根據表的資料變化量自動觸發vacuum機制,回收死元組。 但是在vacuum受到MVCC機制影響,清理資料會檢查資料庫裡最老的交易。 因此除了開啟autovacuum,還需要控制好資料庫內最長的交易。 所以需要監控pg_stat_activity中xact_start不為空的事務,判斷長事務。 如果遇到一直處於idle in transaction狀態的連接,一定要檢查處理。

安全審計
openGauss資料庫提供了安全性稽核功能,可以設定相關稽核參數,將稽核日誌記錄下來,透過sql函數pg_query_audit查看稽核記錄。

下表展示了審計相關的配置項目。 其中DML操作和SELECT操作審計功能建議關閉,因為審計量太大了。

配置項

描述

使用者登入、登出審計

參數:audit_login_logout 預設值為7,表示開啟使用者登入、登出的稽核功能。 設定為0表示關閉使用者登入、登出的審計功能。 不建議設定0和7之外的值。

資料庫啟動、停止、復原和切換審計

參數:audit_database_process 預設值為1,表示開啟資料庫啟動、停止、復原和切換的稽核功能。

用戶鎖定和解鎖審計

參數:audit_user_locked 預設值為1,表示開啟稽核使用者鎖定和解鎖功能。

使用者存取越權審計

參數:audit_user_violation 預設值為0,表示關閉使用者越權操作審計功能。

授權和回收權限審計

參數:audit_grant_revoke 預設值為1,表示開啟稽核使用者權限授予與回收功能。

資料庫物件的CREATE,ALTER,DROP操作審計

參數:audit_system_object 預設值為12295,表示只對DATABASE、SCHEMA、USER、DATA SOURCE這四類資料庫物件的CREATE、ALTER、DROP操作進行稽核。

具體表的INSERT、UPDATE和DELETE操作審計

參數:audit_dml_state 預設值為0,表示關閉特定表的DML操作(SELECT除外)稽核功能。

SELECT操作審計

參數:audit_dml_state_select 預設值為0,表示關閉SELECT操作審計功能。

COPY審計

參數:audit_copy_exec 預設值為0,表示關閉copy操作審計功能。

預存程序和自訂函數的執行審計

參數:audit_function_exec 預設值為0,表示不記錄預存程序和自訂函數的執行稽核日誌。

SET審計

參數:audit_set_parameter 預設值為1,表示記錄set操作稽核日誌

如果需要針對特殊使用者進行SQL層級的審計,可以使用AUDIT POLICY統一審計方式。 打開enable_security_policy開關統一稽核原則才可以生效。

統一審計預設輸出節點的rsyslog日誌中,在作業系統後台服務設定檔/etc/rsyslog.conf中加入程式碼:

local0.* /var/log/localmessages

執行如下命令:

sudo touch /var/log/localmessages

sudo chmod 600 localmessages

sudo systemctl restart rsyslog

然後透過建立 AUDIT POLICY來實現。

CREATE AUDIT POLICY [ IF NOT EXISTS ] policy_name { { privilege_audit_clause | access_audit_clause } [ filter_group_clause ] [ ENABLE | DISABLE ] };

例如僅審計user1用戶的iud操作:

CREATE AUDIT POLICY adt1 ACCESS INSERT,UPDATE,DELETE FILTER ON ROLES(user1);

監控告警
對於企業級的資料庫部署維警,監控警報和緊急處置處理是最重要的。 對於openGauss的監控告警需要達到的目標是能夠準確發現問題並告警,能夠快速基於監控數據分析根因並處理。 為了達成這個目標,建議openGauss資料庫的監控一方面要全面擷取效能和狀態指標,另一方面對於關鍵指標實現準確警告。

監控
openGauss提供了許多監控視圖。 特別是dbe_perf模式下的監控視圖,內容包括OS、Instance、Memory、File、Object、Workload、Session/Thread、Transaction、Query、Cache/IO、Utility、Lock、Wait Events、Configuration、Operator和Workload Manager等對象 的監控。 這些監控視圖也是WDR報表的快照來源。 建議統一採集這些效能快照視圖數據,透過智慧運維管理和分析。

告警
相對於監控資料收集的全面性,警告指標需要挑選全域有意義的物件。 重要的警告有監控資料庫狀態、主從複製狀態、線上會話數量、等待會話數量、長事務、長SQL、死鎖、回滾語句數等。

備份恢復
openGauss資料庫支援的備份方式還是比較全面的。 而企業級的資料庫在這方面要求也很高。 一方面為了出問題盡快恢復,資料庫定期備份策略都比較激進,另一方面備份過程還要盡量減少效能影響和資源佔用。 例如銀行一般每天都會備份全量資料庫,時刻備份歸檔日誌,為了減少效能影響,備份會選擇從庫執行。 如果是遠端備份,那麼也會採用單獨的備份網段,與生產業務網隔離。

許多國內備份廠商目前也一直在測試備份openGauss資料庫,相信很快就會有類似NBU這樣的備份產品出現,並在企業級應用。 openGauss資料庫支援遠端備份,目前也可以建立基於網路的備份伺服器,透過備份專用網,統一調度管理所有資料庫的備份。

結束語
其實做好openGauss企業級部署,就是拿之前對於Db2和Oracle的運維標準來建置openGauss資料庫的維運體系。 openGauss資料庫技術特性與這些商業資料庫相比差異不大,目前欠缺的也只是生態和產品成熟性。 相信這兩方面會越來越好,因此我對於openGauss資料庫在企業中的應用前景非常看好,也希望其盡快成為一個合格的國產替代品。

思享家丨IT 技術驅動永續發展

思科聯天下
作者:思科大中華區高階架構師 王海鷹

思享家
是一個介紹如何利用思科先進技術解決客戶難題的欄位。 每期聚焦一個技術熱點或應用場景,邀請資深思科技術專家深入淺出地介紹,為讀者提供實用性強的建議。

11 月 30 日,190 多個國家在杜拜舉行第 28 屆聯合國氣候變遷大會(COP28)。 為期兩週的大會預計將會有超 7 萬人參加,這將成為有史以來規模最大的一次氣候大會。 本次大會將第一次正式評估 2015 年《巴黎協定》的進展,這將是全球在遏制污染性溫室氣體排放方面取得進展的嚴格評估。 《巴黎協定》提出將全球暖化幅度控制在工業化前水準 1.5℃ 以下的目標。 根據預計,今年將是有史以來地球最熱的一年,科學界表示,一旦超過了 1.5℃ 閾值,人類將難以適應日益加劇的野火、熱浪、乾旱和風暴。

以永續發展因應氣候變遷成為世界的主流發展趨勢,ESG 也成為衡量永續發展的重要指標。 越來越多的主流投資機構在評估標的時,從單純重視財務盈利,開始轉向將ESG 與盈利並重,重新界定“什麼是好公司”,從而探索出一條可持續的企業發展路徑,使得企業在 商業價值和社會責任之間取得平衡。 可見,永續發展不再只是一個理念,而與各大企業、組織甚至每一個人都密切相關。 根據埃森哲的一項研究,73% 的執行長認為成為「真正可持續且負責任的企業」 是其首要任務;同時IDC 表明,62% 的公司認為IT 投資對於實現永續發展目標非常或極其 重要。

數位化和永續發展
如果沒有強大的技術策略,實現永續發展目標困難重重。 埃森哲公司的研究表明,無論是加速淨零排放轉型,還是建立更永續的價值鏈,科技都是實現永續發展的重要推動因素。 對大多數企業來說,永續發展是另一個數位化發展的創新和機會。 IT 將承擔雙重任務——從減少自身排放,到充當業務運營的催化劑。 一方面,他們是高能源消耗者,例如資料中心屬於能源密集型,而不斷增長的新興技術對電力需求還在提高,這包括5G 技術和訓練人工智慧(AI) 模型等;另一方面,IT 技術,以及和OT 技術的融合在永續發展的設計和執行中發揮關鍵作用。 融合的智慧技術有助於量化、監控和預測能源使用情況,將有助於優化業務流程優,並顯著提高效率。

在通往永續發展的道路上,思科與您一路同行

• 在永續發展上, 思科是實踐者,也是業界的領導者。 我們致力於在營運、供應鏈和產品使用方面大幅減少溫室氣體的排放。 從研發層面改善產品的效能,在生產環節使用數位工廠技術和再生能源,同時在思科所有業務中嵌入永續發展和循環經濟原則。 我們制定了一項基於科學的目標(SBTi),到 2040 年在整個價值鏈中實現溫室氣體 (GHG) 淨排放量為零。

從客戶的角度來看,思科的技術創新和實務經驗有助於減少範圍 2 和範圍 3 的排放。 例如,我們的智慧建築和智慧工作空間技術,包括我們的環境監測,可以幫助減少客戶設施能源消耗中的排放。 我們的混合工作技術和減少出行實務有助於公司減少商務旅行和員工通勤範圍 3 類別的排放。 我們的永續網路基礎設施和資料中心加上我們的節能設計,有助於透過減少範圍 2 中的電力消耗以及範圍 3 中購買的商品和服務以及資本貨物的電力來減少排放。 同時,我們對硬體的回收再利用,高可靠性硬體設計和永續包裝可減少營運中的浪費,這是範圍 3 的一部分。 因此, 在履行最佳實務的同時,思科也成為您優秀的綠色供應商。

思科的永續發展方案包含廣泛的產品和技術:

• 從混合辦公到智慧建築和工作空間的解決方案。 採用混合辦公室解決方案,有助於減少通勤和出差,不僅優化了工作流程和效率,也能大幅降低營運的碳足跡。 透過智慧建築解決方案,將提高建築環境的能源效率,並保障工作空間的健康與舒適,保障員工體驗,最終提高生產力。 例如,Cisco Spaces 利用思科網路基礎設施—— 接入點、交換器、攝影機、協作設備和感測器,以網路設施整合的方式和較低的TCO 獲得建築物內人員和事物的位置訊號,並將3D 地圖 和即時佔用資訊結合,讓您的建築變得更加智能,工作空間的環境健康和使用情況也一目了然。

• 從永續的網路基礎架構到永續的資料中心。 從製造到生命週期的整個過程,Catalyst 系列交換、路由和無線產品從設計之初就充分考慮了可持續性發展需求,新一代的有線無線網路採用了多重的能效優化設計,在大幅提升性能的 基礎上可降低20% 以上的能耗。 而新一代資料中心設計不斷發展和調整,以Silicon One 晶片為例,可以減少95% 能耗,增加35% 頻寬,我們的系統設計和軟體有助於優化應用體驗,有助於實現永續運營 。

• 協助 IT 將網路轉變為能源管理控制平面,以優化能源消耗、降低成本、最大限度地減少碳足跡,並監控整個組織的能源使用和能源網路。 例如,思科Meraki 基於雲端管理的全端平台,它整合了無線、交換、安全、視訊監控和IoT 感測器等設備的運行,將用戶IoT 設備,本地和雲端透過符合高安全標準的方式連接,並 真正做到即插即用。 無需在本地或雲端部署專用伺服器,簡單管理、無限擴展,降低了傳統架構的高昂維護成本。

得益於思科設備及管理平台的可持續發展特性和開放API, 思科對線上設備的能耗可實現精準的測量和監控,聯合網絡內置或獨立的多樣化的傳感器可幫助企業實現全面精細化的 碳排查和碳管理,多維度的數據視覺將幫助企業管理者了解業務、設施和能耗的真實關係;根據基於數據驅動的洞察給予優化建議。 憑藉網路互聯進而實現自動化連動和迭代,加強企業永續發展的創新和雙向業務設計。

採取行動
如果您正在製定永續發展策略,則需要不斷尋找創新機會,創造業務價值,並重新評估目標。 Gartner 的最新研究報告強調,IT 主管不應只是被動應對來自利害關係人和監管機構的壓力,而應以此為契機主動支持變革,從而發現新的成長機會,例如創新或採用新的產品和業務 模式。 在高度整合的全數位化淨零時代,網路是關鍵的推動因素。 在掌握淨零排放進度時需要擷取、監控、衡量和報告大量的數據,因此對先進網路有更多的要求。 這是為了確保有效地收集、分析和保護數據,以實現自動化。 未來我會給大家詳細介紹思科在這方面的解決方案和產品。 思科已準備就緒,隨時可與您攜手應對此關鍵挑戰。 在滿足人類需求和實現永續未來之間,思科成就無盡可能。