什么是英特爾傲騰技術(shù)？

無晶體管設(shè)計(jì)數(shù)據(jù)按位級別寫入,因此每個(gè)單元的狀態(tài)可以獨(dú)立于其他單元被改變?yōu)?或1

英特爾傲騰Pmem和SSD填補(bǔ)數(shù)據(jù)中心計(jì)算和存儲(chǔ)間的差距

測試背景

由于Redis實(shí)例規(guī)模比較大45000+，使用服務(wù)器數(shù)量多2000+，而且使用內(nèi)存存儲(chǔ)成本相比磁盤要高很多，基于Redis集群進(jìn)行現(xiàn)狀分析，針對以下集群決定使用傲騰AEP存儲(chǔ)進(jìn)行成本優(yōu)化。

1.請求量低的小集群非常多，部署比較分散，服務(wù)器資源成本高。

2.大容量集群每次申請200G到2T容量不等，使用服務(wù)器數(shù)量多。

傲騰AEP上線需要做什么

    傲騰AEP性能如何

    首先性能測試，整體來講跟純內(nèi)存相比有10%左右的損耗，測試數(shù)據(jù)如下。目前我們在該機(jī)型僅支持小集群、大容量的業(yè)務(wù)，目前不存在性能問題。

說明：上圖為當(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é)每秒處理請求個(gè)數(shù)壓測結(jié)果對比。

說明：上圖為當(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é)每秒處理請求個(gè)數(shù)壓測結(jié)果對比。

說明：上圖為當(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毫秒的百分比壓測結(jié)果對比。

說明：上圖為當(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毫秒的百分比壓測結(jié)果對比。

密集部署調(diào)度是否能打散

1.redis集群1個(gè)節(jié)點(diǎn)下主從不在同一個(gè)機(jī)柜組。

2.redis內(nèi)存利用率大于50%不再調(diào)度新實(shí)例

3.一個(gè)機(jī)柜組承載每個(gè)集群不超過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左右。

密集部署遇到的問題

1>.整點(diǎn)cpu高，慢日志數(shù)量增多，業(yè)務(wù)出現(xiàn)規(guī)律性超時(shí)。

原因：

1.每個(gè)docker容器整點(diǎn)執(zhí)行收集Redis客戶端連接，遇到客戶端連接多的情況尤為嚴(yán)重。

2.每個(gè)docker容器整點(diǎn)執(zhí)行收集Redis元信息的任務(wù)。

3.每個(gè)docker容器整點(diǎn)執(zhí)行anacron任務(wù)。

解決方案：

1.降低定時(shí)任務(wù)收集客戶端連接的頻率。

2.隨機(jī)打散定時(shí)任務(wù)的執(zhí)行時(shí)間。

3.去掉不必要的定時(shí)任務(wù)。

2>.sentinel高可用服務(wù)自動(dòng)切換部分失敗。

原因：

1.sentinel服務(wù)線程數(shù)不夠，丟棄部分待處理任務(wù)。

2.sentinel元信息更新失敗問題。

解決方案：

1.優(yōu)化sentinel服務(wù)線程數(shù)。

2.優(yōu)化更新sentinel元信息的版本控制。

3>.sentinel高可用服務(wù)異常切換慢。

原因：

1.異常檢測周期長。

2.域名切換耗時(shí)高。

解決方案：

1.異常檢測周期由原來30s降低到10s。

2.優(yōu)化域名切換接口索引缺失問題由原來平均30s降低到3s。

4>.Redis負(fù)載高，操作系統(tǒng)卡頓。

原因：

1.docker容器管理Redis進(jìn)程，sentinel-agent組件沿用物理機(jī)部署版本，線程數(shù)過高導(dǎo)致操作系統(tǒng)卡。

2.每個(gè)docker容器部署了repl-agent組件。

3.每個(gè)docker容器的cadvisor監(jiān)控項(xiàng)過多。

解決方案：

1.優(yōu)化sentinel-agent組件降低線程數(shù)。

2.下線repl-agent棄用組件。

3.優(yōu)化cadvisor監(jiān)控項(xiàng)數(shù)量

5>./var目錄容量滿出現(xiàn)Redis所在容器被驅(qū)逐。

解決方案：

1.將coredump日志記錄到較大分區(qū)。

2.優(yōu)化各個(gè)分區(qū)容量的使用的報(bào)警等級。

6>.Redis宿主機(jī)重啟后二次調(diào)度，導(dǎo)致數(shù)據(jù)異常。

解決方案：

1.任務(wù)原因?qū)е碌乃拗鳈C(jī)宕機(jī)，自動(dòng)進(jìn)行調(diào)度隔離。

管理方式變更

1>.Redis資源申請 1.目前可以做到Redis資源分鐘級別交付。

2>.增加異常診斷

1.基于Redis、操作系統(tǒng)，中間件層快速聚合分析到歷史時(shí)間段的異常指標(biāo)。生成集群診斷報(bào)告。

2.通過獲取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>.增加集群畫像

1.集群列表頁關(guān)聯(lián)業(yè)務(wù)組，劃分權(quán)限，只顯示各自歸屬集群，方便業(yè)務(wù)方查看。

2.業(yè)務(wù)方更詳細(xì)了解集群基礎(chǔ)信息（架構(gòu)、分片、機(jī)房等）和性能信息（訪問量、容量等指標(biāo)的實(shí)時(shí)統(tǒng)計(jì)和天級統(tǒng)計(jì)）。

3.基礎(chǔ)數(shù)據(jù)完整和準(zhǔn)確，有效實(shí)施后續(xù)自動(dòng)化功能建設(shè)。

4.實(shí)時(shí)統(tǒng)計(jì)、天級統(tǒng)計(jì)信息可定時(shí)產(chǎn)出報(bào)表，分析低訪問量、慢查詢多等集群。

5.集群信息完整，出問題時(shí)可以快速定位業(yè)務(wù)方、訪問源服務(wù)、關(guān)聯(lián)申請?jiān)�工單、操作類型統(tǒng)計(jì)等維度方便排查。

階段工作成本對比

總結(jié)

1.非核心業(yè)務(wù)可以先上AEP，如果性能不夠再遷移到純內(nèi)存服務(wù)器上。

2.目前存量小實(shí)例繼續(xù)進(jìn)行遷移。

3.性能和TCO優(yōu)勢分析： 英特爾？ 傲騰？ 數(shù)據(jù)中心級持久內(nèi)存在新的推薦異構(gòu)存儲(chǔ)系統(tǒng)和升級后 的Redis 服務(wù)中，不僅有著與 DRAM 內(nèi)存相近的性能表現(xiàn)，其大容量 和非易失性還可幫助實(shí)現(xiàn)更優(yōu)的可用性；通過不同的硬件組合，為不 同應(yīng)用場景下的存儲(chǔ)需求提供高性能，高可擴(kuò)展、安全可靠以及低 TCO的解決方案；在滿足應(yīng)用性能需求的同時(shí)，內(nèi)存的采購成本還得 到顯著降低，并減少了集群所需的節(jié)點(diǎn)數(shù)量，進(jìn)而降低了TCO。

責(zé)任編輯：胡金鵬