什么是英特爾傲騰技術(shù)?
無(wú)晶體管設(shè)計(jì)數(shù)據(jù)按位級(jí)別寫(xiě)入,因此每個(gè)單元的狀態(tài)可以獨(dú)立于其他單元被改變?yōu)?或1
英特爾傲騰Pmem和SSD填補(bǔ)數(shù)據(jù)中心計(jì)算和存儲(chǔ)間的差距
測(cè)試背景
由于Redis實(shí)例規(guī)模比較大45000+,使用服務(wù)器數(shù)量多2000+,而且使用內(nèi)存存儲(chǔ)成本相比磁盤(pán)要高很多,基于Redis集群進(jìn)行現(xiàn)狀分析,針對(duì)以下集群決定使用傲騰AEP存儲(chǔ)進(jìn)行成本優(yōu)化。
1.請(qǐng)求量低的小集群非常多,部署比較分散,服務(wù)器資源成本高。
2.大容量集群每次申請(qǐng)200G到2T容量不等,使用服務(wù)器數(shù)量多。
傲騰AEP上線(xiàn)需要做什么
傲騰AEP性能如何
首先性能測(cè)試,整體來(lái)講跟純內(nèi)存相比有10%左右的損耗,測(cè)試數(shù)據(jù)如下。目前我們?cè)谠摍C(jī)型僅支持小集群、大容量的業(yè)務(wù),目前不存在性能問(wèn)題。
說(shuō)明:上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下,在內(nèi)存和傲騰不同存儲(chǔ)上分別運(yùn)行在不同版本3.2.11、4.0.12、5.0.8、6.0.5,當(dāng)set命令value為10、100、1000字節(jié)每秒處理請(qǐng)求個(gè)數(shù)壓測(cè)結(jié)果對(duì)比。
說(shuō)明:上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下,在內(nèi)存和傲騰不同存儲(chǔ)上分別運(yùn)行在不同版本3.2.11、4.0.12、5.0.8、6.0.5,當(dāng)get命令value為10、100、1000字節(jié)每秒處理請(qǐng)求個(gè)數(shù)壓測(cè)結(jié)果對(duì)比。
說(shuō)明:上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下,在內(nèi)存和傲騰不同存儲(chǔ)上分別運(yùn)行在不同版本3.2.11、4.0.12、5.0.8、6.0.5,當(dāng)set命令value為10、100、1000字節(jié)響應(yīng)時(shí)間分別為1、2、3、4毫秒的百分比壓測(cè)結(jié)果對(duì)比。
說(shuō)明:上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下,在內(nèi)存和傲騰不同存儲(chǔ)上分別運(yùn)行在不同版本3.2.11、4.0.12、5.0.8、6.0.5,當(dāng)get命令value為10、100、1000字節(jié)響應(yīng)時(shí)間分別為1、2、3、4毫秒的百分比壓測(cè)結(jié)果對(duì)比。
密集部署調(diào)度是否能打散
1.redis集群1個(gè)節(jié)點(diǎn)下主從不在同一個(gè)機(jī)柜組。
2.redis內(nèi)存利用率大于50%不再調(diào)度新實(shí)例
3.一個(gè)機(jī)柜組承載每個(gè)集群不超過(guò)25%的實(shí)例數(shù)。
4.擴(kuò)容k8s集群中node后新增實(shí)例的打散依然符合以上規(guī)則。
密集部署宕機(jī)業(yè)務(wù)影響范圍
1.業(yè)務(wù)恢復(fù)時(shí)間從實(shí)例不可用到域名切換完成耗時(shí)20~40s之間。
2.拓?fù)浠謴?fù)時(shí)間完全自動(dòng)化,DBA關(guān)注進(jìn)度就好,宕機(jī)服務(wù)器500+G內(nèi)存恢復(fù)需要30min左右。
密集部署遇到的問(wèn)題
1>.整點(diǎn)cpu高,慢日志數(shù)量增多,業(yè)務(wù)出現(xiàn)規(guī)律性超時(shí)。
原因:
1.每個(gè)docker容器整點(diǎn)執(zhí)行收集Redis客戶(hù)端連接,遇到客戶(hù)端連接多的情況尤為嚴(yán)重。
2.每個(gè)docker容器整點(diǎn)執(zhí)行收集Redis元信息的任務(wù)。
3.每個(gè)docker容器整點(diǎn)執(zhí)行anacron任務(wù)。
解決方案:
1.降低定時(shí)任務(wù)收集客戶(hù)端連接的頻率。
2.隨機(jī)打散定時(shí)任務(wù)的執(zhí)行時(shí)間。
3.去掉不必要的定時(shí)任務(wù)。
2>.sentinel高可用服務(wù)自動(dòng)切換部分失敗。
原因:
1.sentinel服務(wù)線(xiàn)程數(shù)不夠,丟棄部分待處理任務(wù)。
2.sentinel元信息更新失敗問(wèn)題。
解決方案:
1.優(yōu)化sentinel服務(wù)線(xiàn)程數(shù)。
2.優(yōu)化更新sentinel元信息的版本控制。
3>.sentinel高可用服務(wù)異常切換慢。
原因:
1.異常檢測(cè)周期長(zhǎng)。
2.域名切換耗時(shí)高。
解決方案:
1.異常檢測(cè)周期由原來(lái)30s降低到10s。
2.優(yōu)化域名切換接口索引缺失問(wèn)題由原來(lái)平均30s降低到3s。
4>.Redis負(fù)載高,操作系統(tǒng)卡頓。
原因:
1.docker容器管理Redis進(jìn)程,sentinel-agent組件沿用物理機(jī)部署版本,線(xiàn)程數(shù)過(guò)高導(dǎo)致操作系統(tǒng)卡。
2.每個(gè)docker容器部署了repl-agent組件。
3.每個(gè)docker容器的cadvisor監(jiān)控項(xiàng)過(guò)多。
解決方案:
1.優(yōu)化sentinel-agent組件降低線(xiàn)程數(shù)。
2.下線(xiàn)repl-agent棄用組件。
3.優(yōu)化cadvisor監(jiān)控項(xiàng)數(shù)量
5>./var目錄容量滿(mǎn)出現(xiàn)Redis所在容器被驅(qū)逐。
解決方案:
1.將coredump日志記錄到較大分區(qū)。
2.優(yōu)化各個(gè)分區(qū)容量的使用的報(bào)警等級(jí)。
6>.Redis宿主機(jī)重啟后二次調(diào)度,導(dǎo)致數(shù)據(jù)異常。
解決方案:
1.任務(wù)原因?qū)е碌乃拗鳈C(jī)宕機(jī),自動(dòng)進(jìn)行調(diào)度隔離。
管理方式變更
1>.Redis資源申請(qǐng) 1.目前可以做到Redis資源分鐘級(jí)別交付。
2>.增加異常診斷
1.基于Redis、操作系統(tǒng),中間件層快速聚合分析到歷史時(shí)間段的異常指標(biāo)。生成集群診斷報(bào)告。
2.通過(guò)獲取Redis實(shí)時(shí)monitor日志,分析出熱點(diǎn)數(shù)據(jù),輸出熱點(diǎn)報(bào)表信息。
3>.異常處理預(yù)案
1.增加了sentinel服務(wù)異常后宕機(jī)批量切換工具。
2.增加了主從同時(shí)宕機(jī)批量從異地備份機(jī)恢復(fù)數(shù)據(jù)的工具。
4>.增加集群畫(huà)像
1.集群列表頁(yè)關(guān)聯(lián)業(yè)務(wù)組,劃分權(quán)限,只顯示各自歸屬集群,方便業(yè)務(wù)方查看。
2.業(yè)務(wù)方更詳細(xì)了解集群基礎(chǔ)信息(架構(gòu)、分片、機(jī)房等)和性能信息(訪(fǎng)問(wèn)量、容量等指標(biāo)的實(shí)時(shí)統(tǒng)計(jì)和天級(jí)統(tǒng)計(jì))。
3.基礎(chǔ)數(shù)據(jù)完整和準(zhǔn)確,有效實(shí)施后續(xù)自動(dòng)化功能建設(shè)。
4.實(shí)時(shí)統(tǒng)計(jì)、天級(jí)統(tǒng)計(jì)信息可定時(shí)產(chǎn)出報(bào)表,分析低訪(fǎng)問(wèn)量、慢查詢(xún)多等集群。
5.集群信息完整,出問(wèn)題時(shí)可以快速定位業(yè)務(wù)方、訪(fǎng)問(wèn)源服務(wù)、關(guān)聯(lián)申請(qǐng)?jiān)�、操作�?lèi)型統(tǒng)計(jì)等維度方便排查。
階段工作成本對(duì)比
總結(jié)
1.非核心業(yè)務(wù)可以先上AEP,如果性能不夠再遷移到純內(nèi)存服務(wù)器上。
2.目前存量小實(shí)例繼續(xù)進(jìn)行遷移。
3.性能和TCO優(yōu)勢(shì)分析: 英特爾? 傲騰? 數(shù)據(jù)中心級(jí)持久內(nèi)存在新的推薦異構(gòu)存儲(chǔ)系統(tǒng)和升級(jí)后 的Redis 服務(wù)中,不僅有著與 DRAM 內(nèi)存相近的性能表現(xiàn),其大容量 和非易失性還可幫助實(shí)現(xiàn)更優(yōu)的可用性;通過(guò)不同的硬件組合,為不 同應(yīng)用場(chǎng)景下的存儲(chǔ)需求提供高性能,高可擴(kuò)展、安全可靠以及低 TCO的解決方案;在滿(mǎn)足應(yīng)用性能需求的同時(shí),內(nèi)存的采購(gòu)成本還得 到顯著降低,并減少了集群所需的節(jié)點(diǎn)數(shù)量,進(jìn)而降低了TCO。