電子發(fā)燒友App
什么是英特爾傲騰技術(shù)？
無晶體管設(shè)計數(shù)據(jù)按位級別寫入,因此每個單元的狀態(tài)可以獨立于其他單元被改變?yōu)?或1
英特爾傲騰Pmem和SSD填補數(shù)據(jù)中心計算和存儲間的差距
測試背景
由于Redis實例規(guī)模比較大45000+，使用服務(wù)器數(shù)量多2000+，而且使用內(nèi)存存儲成本相比磁盤要高很多，基于Redis集群進行現(xiàn)狀分析，針對以下集群決定使用傲騰AEP存儲進行成本優(yōu)化。
1.請求量低的小集群非常多，部署比較分散，服務(wù)器資源成本高。
2.大容量集群每次申請200G到2T容量不等，使用服務(wù)器數(shù)量多。
傲騰AEP上線需要做什么
????傲騰AEP性能如何
????首先性能測試，整體來講跟純內(nèi)存相比有10%左右的損耗，測試數(shù)據(jù)如下。目前我們在該機型僅支持小集群、大容量的業(yè)務(wù)，目前不存在性能問題。
說明：上圖為當Redis單進程cpu負載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當set命令value為10、100、1000字節(jié)每秒處理請求個數(shù)壓測結(jié)果對比。
說明：上圖為當Redis單進程cpu負載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當get命令value為10、100、1000字節(jié)每秒處理請求個數(shù)壓測結(jié)果對比。
說明：上圖為當Redis單進程cpu負載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當set命令value為10、100、1000字節(jié)響應(yīng)時間分別為1、2、3、4毫秒的百分比壓測結(jié)果對比。
說明：上圖為當Redis單進程cpu負載80%左右的情況下，在內(nèi)存和傲騰不同存儲上分別運行在不同版本3.2.11、4.0.12、5.0.8、6.0.5，當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ù)時間完全自動化，DBA關(guān)注進度就好，宕機服務(wù)器500+G內(nèi)存恢復(fù)需要30min左右。
密集部署遇到的問題
1>.整點cpu高，慢日志數(shù)量增多，業(yè)務(wù)出現(xiàn)規(guī)律性超時。
原因：
1.每個docker容器整點執(zhí)行收集Redis客戶端連接，遇到客戶端連接多的情況尤為嚴重。
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負載高，操作系統(tǒng)卡頓。
原因：
1.docker容器管理Redis進程，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宕機，自動進行調(diào)度隔離。
管理方式變更
1>.Redis資源申請 1.目前可以做到Redis資源分鐘級別交付。
2>.增加異常診斷
1.基于Redis、操作系統(tǒng)，中間件層快速聚合分析到歷史時間段的異常指標。生成集群診斷報告。
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ù)方更詳細了解集群基礎(chǔ)信息（架構(gòu)、分片、機房等）和性能信息（訪問量、容量等指標的實時統(tǒng)計和天級統(tǒng)計）。
3.基礎(chǔ)數(shù)據(jù)完整和準確，有效實施后續(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ù)進行遷移。
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ù)量，進而降低了TCO。
工商網(wǎng)監(jiān)
評論