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

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

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

測試背景

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

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

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

傲騰AEP上線需要做什么

    傲騰AEP性能如何

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

說明：上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當(dāng)set命令value為10、100、1000字節(jié)每秒處理請求個數(shù)壓測結(jié)果對比。

說明：上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當(dāng)get命令value為10、100、1000字節(jié)每秒處理請求個數(shù)壓測結(jié)果對比。

說明：上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當(dāng)set命令value為10、100、1000字節(jié)響應(yīng)時間分別為1、2、3、4毫秒的百分比壓測結(jié)果對比。

說明：上圖為當(dāng)Redis單進(jìn)程cpu負(fù)載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當(dāng)get命令value為10、100、1000字節(jié)響應(yīng)時間分別為1、2、3、4毫秒的百分比壓測結(jié)果對比。

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

1.redis集群1個節(jié)點下主從不在同一個機柜組。

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

3.一個機柜組承載每個集群不超過25%的實例數(shù)。

4.擴容k8s集群中node后新增實例的打散依然符合以上規(guī)則。

密集部署宕機業(yè)務(wù)影響范圍

1.業(yè)務(wù)恢復(fù)時間從實例不可用到域名切換完成耗時20~40s之間。

2.拓?fù)浠謴?fù)時間完全自動化，DBA關(guān)注進(jìn)度就好，宕機服務(wù)器500+G內(nèi)存恢復(fù)需要30min左右。

密集部署遇到的問題

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

原因：

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

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

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

解決方案：

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

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

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

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

原因：

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

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

解決方案：

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

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

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

原因：

1.異常檢測周期長。

2.域名切換耗時高。

解決方案：

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

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

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

原因：

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

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

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

解決方案：

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

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

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

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

解決方案：

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

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

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

解決方案：

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

管理方式變更

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

2>.增加異常診斷

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

2.通過獲取Redis實時monitor日志，分析出熱點數(shù)據(jù)，輸出熱點報表信息。

3>.異常處理預(yù)案

1.增加了sentinel服務(wù)異常后宕機批量切換工具。

2.增加了主從同時宕機批量從異地備份機恢復(fù)數(shù)據(jù)的工具。

4>.增加集群畫像

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

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

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

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

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

階段工作成本對比

總結(jié)

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

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

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

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