一種大規(guī)模Redis集群云運維技術
2019-05-23 10:44屠雪真
電腦知識與技術 2019年8期
屠雪真
摘要：Redis是互聯網時代廣泛使用的NoSQL數據庫。隨著數據規(guī)模的快速增長，傳統的運維管理方式已不能滿足應用軟件對Redis集群的大規(guī)模、靈活和高效的部署與運維需求。近年來云計算技術的成熟和Kubernetes的快速發(fā)展，基于容器的微服務架構已成為應用軟件的首選架構。該文從Redis集群的現狀和需求出發(fā)，結合Docker容器管理和微服務關鍵技術，提出一種基于云計算和微服務的大規(guī)模Redis集群云運維方案，實現了Redis集群的云化管理、按需服務和高效運維。通過實驗，證明了該方案在快速部署和便捷運維方面具有較大的優(yōu)勢。
關鍵詞：Redis；NoSQL；云計算；Kubernetes；Docker；微服務
中圖分類號：TP391 文獻標識碼：A
文章編號：1009-3044（2019）08-0001-03
開放科學（資源服務）標識碼（OSID）：
A Large-Scale Redis Cluster Cloud Operation and Maintenance Technology
TU Xue-zhen
（School of Computer and Information Engineering， Henan University， Kaifeng 475001， China）
Abstract： Redis is a NoSQL database widely used in the Internet age. With the rapid growth of data scale， traditional operation and maintenance management methods can no longer meet the large-scale， flexible and efficient maintenance and operation requirements of application software for Redis clusters. With the maturity of cloud computing technology and the rapid development of Kubernetes in recent years， container-based microservice architecture has become the preferred architecture for application software. Based on the current situation and requirements of Redis cluster， combined with Docker container management and micro-service key technologies， this paper proposes a large-scale Redis cluster cloud operation and maintenance scheme， which realizes the efficient operation and maintenance of Redis clusters. Experiments show that the scheme has great advantages in rapid deployment and convenient operation and maintenance.
Key words： redis； NoSQL； cloud computing； Kubernetes； microservice
1引言
隨著信息技術的飛速發(fā)展，許多新型應用面臨著高并發(fā)、低時延、彈性擴展和高可用等挑戰(zhàn)?；趉ey-value的NoSQL數據庫系統憑借高性能、高可擴展性的優(yōu)勢和簡單靈活的數據模型脫穎而出[1]，并在大規(guī)模數據處理和存儲領域得到了廣泛應用。
在諸多的K-V系統中，Redis是應用最廣泛且具有代表性的方案[2]。它支持多種數據類型的存儲和豐富的操作，提供 RDB 和 AOF兩種持久化方式，但這只是其保證數據恢復的措施。Redis適用于多種應用場景，在互聯網和分布式計算領域有很多成功的應用范例。
為了保證效率，Redis的數據存取都是在內存中。由于內存容量的限制，僅使用單臺服務器提供Redis服務在很多應用中是不夠的。Redis在3.0版本后提供了官方的集群化方案，但是其集群化方案在很多場景下還沒有得到充分的驗證，很多使用者根據自己的生產環(huán)境定制解決方案[3]。
隨著數據量的不斷增大，Redis集群的規(guī)模也會變大。例如，某局點用戶規(guī)模10萬，數據量50GB，每秒請求數為600，每次用戶請求操作Redis20次，則Redis的負載為1.2WTPS。使用Redis單實例即可滿足需求，考慮到高可用，可以使用Redis哨兵方案?，F在該局點的用戶規(guī)模增長到1000萬，數據量在2TB左右，需要80臺資源為8C/128G的虛擬機，每臺虛擬機上運行3個Redis實例，則一共需要120個Redis主節(jié)點和120個Redis從節(jié)點。
對于這種大規(guī)模Redis集群，傳統的運維方法遇到了很大的困難和挑戰(zhàn)。首先是耗時長。傳統運維自動化安裝部署方案流程一般為修改配置、上傳版本、啟動程序、校驗服務四個步驟。首選運維工程師需要先在PC客戶端把配置文件修改好，對于Redis集群來講主要需要修改redis.conf中的IP和端口，手動修改或者界面修改；然后執(zhí)行程序和各個安裝部署服務器（一般為FTP服務）建立鏈接并鑒權，上傳版本；再然后執(zhí)行程序遠程執(zhí)行啟動程序服務；最后登錄某一個節(jié)點或者全部節(jié)點，用模擬客戶端訪問校驗服務是否正常。整個流程自動化程度低、耗時比較大。其次是運維難。業(yè)界Redis系統監(jiān)控告警一般基于各個集群節(jié)點的日志信息上報，監(jiān)控中心需要維護各個節(jié)點信息，一旦需要擴縮容，節(jié)點信息發(fā)生變更，需要更新監(jiān)控中心的服務節(jié)點列表，很難做到自動化和業(yè)務無感知。運維人員除了需要熟悉Redis業(yè)務相關運維知識，還需要熟悉組網架構和底層網絡排查，對運維人員的技能要求高。
2 基于微服務的Redis云運維方案
隨著云計算技術的成熟，基礎設施自動化、按需虛擬化和大型集群系統的理念逐步成為主流，應用軟件開發(fā)也從單體架構轉到微服務化架構[4]。將微服務裝入容器進行獨立的部署和擴展，使其具有高可移植性，成為一種必然的趨勢[5]。Kubernetes是主流的分布式容器集群編排管理引擎，用于管理云平臺中多個主機上的容器化應用，為容器集群提供調度服務、服務注冊、服務發(fā)現、資源調度、均衡容災、動態(tài)擴縮容等支持[6]。
本文設計了一種基于云計算技術和微服務架構的Redis集群云運維方案，實現了多種Redis類型（Redis Standalone、Redis Sentinel、Redis Cluster）的快速自動部署和平滑升級，解決Redis實例碎片化現象、提供完善統計、監(jiān)控、運維功能、減少運維成本和誤操作，提高機器的利用率，提供靈活的伸縮性。
在IaaS層采用Openstack和K8S對虛擬機和容器做資源池化，這一層主要是對基礎設施進行管理以給用戶提供資源使用，如提供計算服務、安全備份、負載管理等。IaaS上面是PaaS層，這一層主要是簡化應用的部署、運行等，提供一些通用中間件能力，如消息服務、數據庫服務等[7]。
Redis以公共服務中間件的形式集成到PaaS層[8]。Redis云運維流程如圖1所示。其中，CSM（Common Service Management）是公共服務管理模塊，主要負責公共服務鏡像管理、公共服務資源（硬盤、CPU、內存、網絡）等的管理。MSB是微服務總線模塊，主要負責服務注冊、服務發(fā)現、服務健康檢查、服務路由等功能。
Redis公共服務中包括Redis微服務和Redis Service Broker微服務。Redis Service Broker的作用是檢測Redis服務是否正常，和Redis協議緊密結合。Redis Service Broker的高可用由K8S保證，一旦容器掛掉則由K8S負責重啟。
安裝服務流程。用戶發(fā)起安裝服務請求給CSM，CSM識別出服務類型為Redis，則通過K8S從后臺鏡像倉庫取出Redis 的Service Broker鏡像，運行該鏡像，將運行結果返回給用戶。
創(chuàng)建服務流程。用戶發(fā)送“創(chuàng)建服務請求”給CSM，CSM通過K8S從鏡像倉庫中取出并運行Redis的鏡像。鏡像運行時會自啟動鏡像中的redis-server程序和redis-agent程序，redis-agent啟動后會發(fā)送MSB注冊消息，注冊消息中攜帶redis-server的IP、PORT、密碼等信息。MSB收到注冊消息后，會一方面給Redis-server的IP和PORT分配一個PaaS平臺的唯一服務名，另一方面給Redis Service Broker發(fā)送查詢服務狀態(tài)消息，消息中攜帶redis-server的IP、PORT、密碼等信息。Redis Service Broker收到查詢消息后，會根據IP、PORT、密碼訪問redis-server，執(zhí)行簡單的Set、Get、Del操作來驗證redis-server是否工作正常，然后返回MSB檢測結果。MSB根據檢測結果返回用戶創(chuàng)建服務結果，如果檢測成功，則返回用戶“創(chuàng)建服務成功”，如果檢測失敗，則返回用戶“創(chuàng)建服務失敗”。用戶在創(chuàng)建過程中，每個Redis服務在MSB對應不同且唯一的域名，通過這種方式，可以做到租戶隔離。
服務提供。應用程序通過API把服務名轉換為IP，然后根據IP找到對應的Redis節(jié)點，訪問該節(jié)點提供Redis服務。
2.1 Redis云運維的部署和升級
傳統運維方法采用Redis集群節(jié)點串行升級方式。而云運維方案通過前述的Redis集群云運維流程和docker容器的快速啟動，實現了Redis集群快速自動化安裝部署。
以主備N+N集群模式為例。首先啟動N個Redis微服務容器，PaaS云平臺將這N個容器均勻分布在虛擬化資源上，PaaS自身提供資源的負載均衡啟動功能。這些容器內部集成Redis-server、Redis-agent程序。
然后啟動控制中心容器，啟動控制中心容器時，通過環(huán)境變量獲取到啟動好的N個容器的IP地址，結合默認Redis端口將N個Redis程序添加到Redis集群中，這N個Redis程序成為集群的master。
然后在控制中心容器中調用PaaS接口再次批量啟動N個容器，并且調用PaaS接口獲取到新啟動容器的IP，然后逐個把這些Redis程序作為slave添加到集群中。從而完成集群的快速安裝部署。
需要注意的是，控制中心無法感知并且也沒有必要感知到容器所在服務器信息，如果slave和master分到同一臺虛擬機上，也沒關系，一旦整臺虛擬機出現異常，該虛擬機上所有的docker容器會啟動在另一臺虛擬機上，這個機制保證在由于硬件問題或者系統問題導致的某個復制組整體異常時繼續(xù)提供正常服務。
云運維方案也能解決Redis集群平滑升級耗時長的問題[8]。平滑升級時，由控制中心向所有的復制組的slave發(fā)送shutdown指令，所有的復制組升級的步驟是同步并行執(zhí)行的，使得升級的時間可以在一個可控范圍之內，不會和集群的節(jié)點數目呈線性關系。
2.2 Redis云運維的日常維護
Redis云運維的日常維護主要有系統監(jiān)控告警和在線動態(tài)修改配置。
Redis云運維從4個維度對Redis服務進行監(jiān)控運維。
·告警監(jiān)控主要對平臺的當前告警、歷史告警和通知進行展示，用戶可以對告警進行查詢和確認等操作。
·性能監(jiān)控主要對平臺的節(jié)點、組件和組件實例的性能數據進行展示，包括CPU、內存、磁盤等。
·事件頁面提供PaaS平臺組件上報的事件呈現，查詢，過濾。
·日志頁面提供PaaS平臺組件調測日志和用戶操作日志的查詢，過濾，導出及下載功能。
Redis規(guī)?；\維遇到的一個比較常見的問題是修改配置，比如客戶需要定期修改Redis的密碼以提高Redis數據的安全性，假設我們的Redis集群有上百個集群節(jié)點，手動修改顯然不合適，我們需要批量修改Redis配置信息。
具體實施方案如下：首先用戶在用戶界面以key-value形式輸入要修改的配置，比如：
云運維方案把Redis需要保存的數據文件，比如redis.conf存放入Ceph文件系統，如果Redis容器重啟，容器里的Redis服務自動從Ceph的redis.conf配置文件加載配置信息。Ceph是一個可靠地、自動重均衡、自動恢復的分布式存儲系統，可以提供文件、對象和塊存儲服務[10]。由于Ceph采用了CRUSH算法、HASH環(huán)等良好設計，使得它不存在單點故障問題，隨著規(guī)模的擴大性能也不會受到影響。
2.3云運維下的Redis實例
雖然Docker提供了應用程序打包，Kubernetes提供了應用部署和調度機制，但它在Pod-to-Pod通信網絡上還缺少一個普適的解決方案。Kubernetes默認網絡采用的方法是創(chuàng)建具有IP范圍的虛擬網橋，然后在每個主機上手動添加主機之間的路由，該方法管理配置比較困難。采用容器網絡接口（CNI）和網絡插件的方法可以自動生成基本配置，簡化了網絡的創(chuàng)建和管理。云運維方案在創(chuàng)建CNI插件時，使用了Flannel方案，提供了更好的異構資源兼容性。
如圖2所示，云運維環(huán)境下的Redis實例運行在docker容器中，采用libnetwork內置驅動的bridge網絡模式，libnetwork將創(chuàng)建出來的Docker容器連接到Docker網橋上。
為了容器之間能夠數據通信，Docker在各個容器之間創(chuàng)建了一個docker0網橋，類似于交換機[11]，該網橋以eth pair連接各容器的網絡，容器中的數據通過docker0網橋轉發(fā)到eth0網卡，網橋上的veth網卡設備相當于交換機上的端口，可以將多個容器或虛擬機連接在上面，這些端口工作在二層，所以是不需要配置IP信息的。圖中docker0網橋就為連在其上的容器轉發(fā)數據幀，使得同一臺宿主機上的Docker容器之間可以相互通信。
3實驗結果及分析
實驗中使用8臺服務器，配置如下： 64 GB 內存，酷睿2 雙核CPU，500 GB 硬盤，CentOS Linux release 7.3.1611 操作系統。實驗使用Redis版本4.0.10。
測試結果如圖3所示。在部署耗時方面，傳統運維自動化部署時間隨著Redis集群節(jié)點數目增多會逐漸增大，而PaaS方案的Redis自動化安裝部署時間可以控制部署時間在一個很小的數據范圍之內。
為了檢驗云運維對Redis性能的影響，我們做了虛擬機和云運維環(huán)境的性能對比實驗。Redis配置為：HA（1主2從），Redis maxmemory為2G，Payload大小64字節(jié)/512字節(jié)/1K/2K，客戶端鏈接數32/64/96/128/160個鏈接。測試結果如圖3右圖所示，Redis性能在云運維環(huán)境下和純虛擬機環(huán)境下大致相當，性能損耗在可接受范圍內。
4 結束語
在傳統IT架構向云計算架構轉型的過程中，云計算和基于Docker的微服務架構的技術特點、管理理念和服務理念相互融合，對構建云原生應用帶來較高的參考價值?；诜植际侥Ｐ偷腞edis在帶來高性能、高可擴展性的同時，也加大了部署和運維的難度。Redis集群的規(guī)?；\維還沒有統一的標準規(guī)范?；趯υ朴嬎恪⑽⒎?、Docker和K8S技術的研究，本文提出的Redis集群云運維方案，實現了多種Redis高可用方案的有效管理，簡化運維并提升效率，滿足了企業(yè)低成本地打造大規(guī)模Redis服務集群的需求。
但是，受限于虛擬化和docker自身的機制，Redis在容器內的性能還不能和物理裸機相等。隨著容器技術的快不斷成熟，相信這個問題將得到有效解決。
參考文獻：
[1]馬文龍，朱妤晴，蔣德鈞，等.Key-Value型NoSQL本地存儲系統研究[J].計算機學報，2018，41（8）：1722-1751.
[2]姚經緯，楊福軍.Redis分布式緩存技術在Hadoop平臺上的應用[J].計算機技術與發(fā)展，2017，27（6）：146-150.
[3]閆明.高可用可擴展集群化Redis設計與實現[D].西安：西安電子科技大學，2016.
[4]陳春霞.基于容器的微服務架構的淺析[J].信息系統工程，2016（3）：95-96.
[5]YOUSIF M.Microservices[J].IEEE Cloud Computing，2016，3（5）：4-5.
[6]龔正，吳治輝，葉伙榮，等.Kubernets權威指南[M].北京：電子工業(yè)出版社，2016.
[7]劉歡歡，麻志毅，陳泓婕 .基于PaaS的云應用軟件部署環(huán)境的元模型[J].計算機科學，2015，42（10）：45-49.
[8]師德清. 基于Docker 的PaaS 架構設計研究[J].信息與電腦，2017（8）：35-36.
[9]田玉靖，張晨光，任女爾.基于Docker的Redis緩存架構的研究[J].電腦知識與技術，2015，11（23）：56-58.
[10]楊飛，朱志祥，梁小江.基于Ceph對象存儲集群的高可用設計與實現.微電子學與計算機，2016，33（01）：60-64.
[11]郭棟，王偉，曾國蓀.一種基于微服務架構的新型云件PaaS平臺[J]. 信息網絡安全，2015（11）：15-20.
【通聯編輯：唐一東】
猜你喜歡
中國中醫(yī)藥圖書情報(2016年6期)2017-01-17
科教導刊(2016年27期)2016-11-15
大學教育(2016年9期)2016-10-09
