精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

當前位置:數據中心技術專區 → 正文

思享家 | 網工歷險記 - 拿什么拯救你我的頭發?

責任編輯:cres 作者:魏航 |來源:企業網D1Net  2021-03-02 10:02:28 本文摘自:投稿

本文作者:魏航
思科首席架構師
 
思享家
是一個介紹如何利用思科先進技術解決客戶難題的欄目。每期聚焦一個技術熱點或應用場景,邀請資深思科技術專家深入淺出地介紹,為讀者提供實用性強的建議。
 
防患未然、主動運維一直是網工們夢寐以求的運維境界。
 
然而雖然擁有看似強大的網管工具,但網工們仍飽受莫名其妙的網絡問題的折磨,以至于網絡經常成為 IT 故障默認的背鍋俠。
 
舉個栗子:一場真實經歷的網工噩夢 —— 幽靈丟包。
 
最早的故障現象是一部分用戶反映登錄超時。于是網工們開始檢查網絡,網管工具顯示自然是一片綠,看不出什么問題,ping 故障服務器集群,竟然發現在部分主機上 ping 不通,這些主機分布在不同網段,完全看不出規律。
 
奇怪的是有些主機換個網段或換個 IP 又能 ping 通,于是認定通路上或許存在路由黑洞或訪問控制列表,一通檢查后都排除了。一個網工偶然發現很多不能 ping 通目標服務器的主機是完全能訪問目標應用的,是否 ping 通好像和應用是否成功登錄沒有關系,這下網工們集體陷入懵圈……
 
兩天后,問題最終被找出來了,只是網絡主管少不了被內部用戶一通投訴、一線網工們少不了多掉了許多頭發。
 
是網工們的工具不夠強大,發現不了故障嗎?
 
其實工具是可以監測到問題端倪的,那為什么管理員又難以找到原因呢?
 
你以為用戶體驗的惡化是這樣的:
 
 
但現實中用戶體驗的惡化卻常常是這樣的:
 
 
這種現象揭示出,工具雖然強大,但它們都是 “ 豎井化 ” 的本領域的 “ 專家 ” 。它們對系統健康評判標準基于本領域的各類測量閾值,什么算 “ 綠 ” 什么算 “ 黃 ” 什么算 “ 紅 ”,卻缺乏端到端的全局視野。
 
網工們如果不想被各種假警報吵得睡不著覺,就會把報警的閾值門檻設得高一點,很多 “ 端倪 ” 雖然能被發現,但只要算不上災難就不會報警。
 
隨著現代數據中心系統復雜性的升高,單一領域崩潰級的故障導致用戶體驗惡化的 “ 好事 ” 很難遇到了,往往是以多領域 “ 亞健康 ” 的持續積累、跨領域的配合失調等方式造成用戶體驗惡化的。
 
多領域、全局視野衡量用戶應用體驗的測量工具到底存在嗎?
 
業界的應用性能監測系統( Application Performance Monitor,APM )大多具備端到端應用健康度視圖,形如下面:
 
 
但這樣的 APM 工具缺乏每個單獨領域的專業性,又無法檢測出問題領域內故障產生的根因。
 
背鍋俠網工們真的沒法保住頭發了嗎?
 
聰明的你一定想到了,如果由同一家廠商提供世界上最好的 APM 和最好的數據中心基礎架構會怎樣呢?
 
讓我們看看 Gartner 魔力象限 APM 領導象限的 Cisco AppDynamics 和數據中心網絡領導象限的 Cisco ACI 這對 “ 夢幻組合 ” 是如何解決這個問題的吧。
 
AppDynamics 通過應用內的探針敏銳的捕捉到端到端用戶體驗的惡化,就像下圖典型的 3-Tier 應用( 前端、應用、數據庫 )中影響用戶體驗的那一段被用鮮紅的線段標識出來。
 
 
雖然 AppDynamics 能夠標識出應用體驗惡化的應用層級位置,但對基礎架構發生了什么并不完全知曉,我們把鼠標放在故障層級的位置就會變成手指形狀,點擊它就會彈出下圖的菜單。
 
 
點擊菜單中的 Troubleshoot( Cisco APIC ),Cisco ACI 的 SDN 控制器 APIC 的圖形界面就會自動登錄并打開 ACI 著名的故障診斷工具箱 Visibility & Troubleshooting 。
 
 
工具箱啟用高強度診斷模式,針對 AppDynamics 告知的與故障層級相關的IP地址、協議和 TCP/UDP 端口號收集過去 24 小時內的所有數據記錄,如異常告警、端口狀態變化、配置修改、流量統計、Buffer 變化、丟包和延遲數據等等,并提供自動化的全路徑可視化跟蹤、逐包遙測、安全策略分析和端口鏡像工具等等。
 
如果沒有 AppDynamics 提供與業務體驗直接相關的精準上下文,這樣強度的診斷是不可能常態性的發生在網絡中所有的通訊節點之間的。
 
背鍋俠網工們的頭發終于有救了
 
正是這種 “ 意圖 ” 明確的診斷需求,引導我們把日常忽視的眾多模棱兩可的基礎架構閾值告警關聯起來,重新聚焦審視,從而幫助我們定位到了問題的根因 —— 正如上圖中右下角被過濾出的故障告警所示,問題沒有發生在 Fabric 上,而是虛機網絡內部。
 
原來這又是一起因為管理員之間的誤解而導致的跨領域配合失誤的事故——
 
在給應用集群增加新服務器時,網絡管理員認為服務器雙上連應當是基于LACP端口捆綁的負載均衡,而服務器管理員則認為是基于端點動態pinning的雙網卡負載均衡,如果不幸這臺服務器被負載均衡命中,又在Fabric的Hash中被命中到了錯誤的網卡上,丟包就會出現,而稍稍改變一個條件可能就會命中正常的服務器或問題服務器的正確網卡上,一切就又會正常。
 
如果沒有能夠關聯基礎架構能力的跨領域視野的檢測系統,即便反復在狹窄領域內自查,這種幽靈丟包原因也很難被發現。
 
找到問題根源,解決問題就不是難事了。下面是排除故障后ACI診斷工具箱和AppDynamics的正常狀態顯示:
 
 
這種故障診斷方法具備普遍適用性嗎?換一種故障是不是就無能為力了呢?
 
當然不是!
 
前面雖然只是一個典型案例,但是揭示了一種全新的智能主動運維架構 —— 基于意圖的自動化運維。
 
AppDynamics 代表了一大類能夠自動生成診斷意圖的智能洞見引擎( Insights Engine ),而 ACI APIC 則代表了另一大類能夠高效采集基礎架構大數據、能夠根據意圖自動化完成故障診斷和故障恢復的自動化引擎( Automation Engine ),兩類引擎的有機互動,構建了新型的基于意圖的主動運維系統。
 
洞見引擎和自動化引擎還有哪些新技術?它們和AI、大數據分析處理有哪些聯系?它們的互動還能產生哪些神奇的化學反應?
 
敬請關注下期,精彩仍將繼續!
 

關鍵字:數據中心思科

本文摘自:投稿

x 思享家 | 網工歷險記 - 拿什么拯救你我的頭發? 掃一掃
分享本文到朋友圈
當前位置:數據中心技術專區 → 正文

思享家 | 網工歷險記 - 拿什么拯救你我的頭發?

責任編輯:cres 作者:魏航 |來源:企業網D1Net  2021-03-02 10:02:28 本文摘自:投稿

本文作者:魏航
思科首席架構師
 
思享家
是一個介紹如何利用思科先進技術解決客戶難題的欄目。每期聚焦一個技術熱點或應用場景,邀請資深思科技術專家深入淺出地介紹,為讀者提供實用性強的建議。
 
防患未然、主動運維一直是網工們夢寐以求的運維境界。
 
然而雖然擁有看似強大的網管工具,但網工們仍飽受莫名其妙的網絡問題的折磨,以至于網絡經常成為 IT 故障默認的背鍋俠。
 
舉個栗子:一場真實經歷的網工噩夢 —— 幽靈丟包。
 
最早的故障現象是一部分用戶反映登錄超時。于是網工們開始檢查網絡,網管工具顯示自然是一片綠,看不出什么問題,ping 故障服務器集群,竟然發現在部分主機上 ping 不通,這些主機分布在不同網段,完全看不出規律。
 
奇怪的是有些主機換個網段或換個 IP 又能 ping 通,于是認定通路上或許存在路由黑洞或訪問控制列表,一通檢查后都排除了。一個網工偶然發現很多不能 ping 通目標服務器的主機是完全能訪問目標應用的,是否 ping 通好像和應用是否成功登錄沒有關系,這下網工們集體陷入懵圈……
 
兩天后,問題最終被找出來了,只是網絡主管少不了被內部用戶一通投訴、一線網工們少不了多掉了許多頭發。
 
是網工們的工具不夠強大,發現不了故障嗎?
 
其實工具是可以監測到問題端倪的,那為什么管理員又難以找到原因呢?
 
你以為用戶體驗的惡化是這樣的:
 
 
但現實中用戶體驗的惡化卻常常是這樣的:
 
 
這種現象揭示出,工具雖然強大,但它們都是 “ 豎井化 ” 的本領域的 “ 專家 ” 。它們對系統健康評判標準基于本領域的各類測量閾值,什么算 “ 綠 ” 什么算 “ 黃 ” 什么算 “ 紅 ”,卻缺乏端到端的全局視野。
 
網工們如果不想被各種假警報吵得睡不著覺,就會把報警的閾值門檻設得高一點,很多 “ 端倪 ” 雖然能被發現,但只要算不上災難就不會報警。
 
隨著現代數據中心系統復雜性的升高,單一領域崩潰級的故障導致用戶體驗惡化的 “ 好事 ” 很難遇到了,往往是以多領域 “ 亞健康 ” 的持續積累、跨領域的配合失調等方式造成用戶體驗惡化的。
 
多領域、全局視野衡量用戶應用體驗的測量工具到底存在嗎?
 
業界的應用性能監測系統( Application Performance Monitor,APM )大多具備端到端應用健康度視圖,形如下面:
 
 
但這樣的 APM 工具缺乏每個單獨領域的專業性,又無法檢測出問題領域內故障產生的根因。
 
背鍋俠網工們真的沒法保住頭發了嗎?
 
聰明的你一定想到了,如果由同一家廠商提供世界上最好的 APM 和最好的數據中心基礎架構會怎樣呢?
 
讓我們看看 Gartner 魔力象限 APM 領導象限的 Cisco AppDynamics 和數據中心網絡領導象限的 Cisco ACI 這對 “ 夢幻組合 ” 是如何解決這個問題的吧。
 
AppDynamics 通過應用內的探針敏銳的捕捉到端到端用戶體驗的惡化,就像下圖典型的 3-Tier 應用( 前端、應用、數據庫 )中影響用戶體驗的那一段被用鮮紅的線段標識出來。
 
 
雖然 AppDynamics 能夠標識出應用體驗惡化的應用層級位置,但對基礎架構發生了什么并不完全知曉,我們把鼠標放在故障層級的位置就會變成手指形狀,點擊它就會彈出下圖的菜單。
 
 
點擊菜單中的 Troubleshoot( Cisco APIC ),Cisco ACI 的 SDN 控制器 APIC 的圖形界面就會自動登錄并打開 ACI 著名的故障診斷工具箱 Visibility & Troubleshooting 。
 
 
工具箱啟用高強度診斷模式,針對 AppDynamics 告知的與故障層級相關的IP地址、協議和 TCP/UDP 端口號收集過去 24 小時內的所有數據記錄,如異常告警、端口狀態變化、配置修改、流量統計、Buffer 變化、丟包和延遲數據等等,并提供自動化的全路徑可視化跟蹤、逐包遙測、安全策略分析和端口鏡像工具等等。
 
如果沒有 AppDynamics 提供與業務體驗直接相關的精準上下文,這樣強度的診斷是不可能常態性的發生在網絡中所有的通訊節點之間的。
 
背鍋俠網工們的頭發終于有救了
 
正是這種 “ 意圖 ” 明確的診斷需求,引導我們把日常忽視的眾多模棱兩可的基礎架構閾值告警關聯起來,重新聚焦審視,從而幫助我們定位到了問題的根因 —— 正如上圖中右下角被過濾出的故障告警所示,問題沒有發生在 Fabric 上,而是虛機網絡內部。
 
原來這又是一起因為管理員之間的誤解而導致的跨領域配合失誤的事故——
 
在給應用集群增加新服務器時,網絡管理員認為服務器雙上連應當是基于LACP端口捆綁的負載均衡,而服務器管理員則認為是基于端點動態pinning的雙網卡負載均衡,如果不幸這臺服務器被負載均衡命中,又在Fabric的Hash中被命中到了錯誤的網卡上,丟包就會出現,而稍稍改變一個條件可能就會命中正常的服務器或問題服務器的正確網卡上,一切就又會正常。
 
如果沒有能夠關聯基礎架構能力的跨領域視野的檢測系統,即便反復在狹窄領域內自查,這種幽靈丟包原因也很難被發現。
 
找到問題根源,解決問題就不是難事了。下面是排除故障后ACI診斷工具箱和AppDynamics的正常狀態顯示:
 
 
這種故障診斷方法具備普遍適用性嗎?換一種故障是不是就無能為力了呢?
 
當然不是!
 
前面雖然只是一個典型案例,但是揭示了一種全新的智能主動運維架構 —— 基于意圖的自動化運維。
 
AppDynamics 代表了一大類能夠自動生成診斷意圖的智能洞見引擎( Insights Engine ),而 ACI APIC 則代表了另一大類能夠高效采集基礎架構大數據、能夠根據意圖自動化完成故障診斷和故障恢復的自動化引擎( Automation Engine ),兩類引擎的有機互動,構建了新型的基于意圖的主動運維系統。
 
洞見引擎和自動化引擎還有哪些新技術?它們和AI、大數據分析處理有哪些聯系?它們的互動還能產生哪些神奇的化學反應?
 
敬請關注下期,精彩仍將繼續!
 
點擊鏈接了解更多:https://www.cisco.com/c/zh_cn/solutions/data-center-virtualization/index.html?dtid=osowct000775&ccid=cc000967

關鍵字:數據中心思科

本文摘自:投稿

電子周刊
回到頂部

關于我們聯系我們版權聲明隱私條款廣告服務友情鏈接投稿中心招賢納士

企業網版權所有 ©2010-2024 京ICP備09108050號-6 京公網安備 11010502049343號

^
  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 宿松县| 家居| 四子王旗| 凤城市| 宝清县| 元氏县| 丹棱县| 上高县| 喀喇沁旗| 南溪县| 冕宁县| 通江县| 泗水县| 东丰县| 格尔木市| 城固县| 库车县| 斗六市| 九龙城区| 武夷山市| 扎赉特旗| 桓仁| 登封市| 新平| 友谊县| 蓝田县| 油尖旺区| 双城市| 南宁市| 靖西县| 云阳县| 全南县| 闽侯县| 太湖县| 方山县| 乡城县| 忻州市| 周宁县| 谢通门县| 星子县| 凭祥市|