博客

  • 思科重新構想人工智慧時代的資料中心與雲端安全

    思科联天下

    ● 思科為人工智慧規模的資料中心和雲端提供動力和保護。 無論應用和裝置如何分佈或聯接,思科均能確保其安全。

    ● 當今高度離散的網路世界,漏洞從出現到被利用的時間正在縮短,而防禦資料中心日益複雜的威脅環境已經超出了人力所能處理的範圍。

    ● Cisco Hypershield 能夠在客戶需要的任何地方提供安全保護,無論是雲端、資料中心、工廠車間或醫院影像室,都能夠隨時隨地保障其安全。

    ● 透過AI原生安全功能,客戶可以自主分段其網絡,無需補丁即可享受分散式和近乎即時的漏洞保護,同時享受零停機時間的自動軟體升級服務。

    2024年4月24日,北京—全球科技領導廠商思科日前正式推出資料中心與雲端安全的全新技術,以因應AI變革對IT基礎設施日益增長的需求。

    思科推出業界首創的Cisco Hypershield,重新建構企業運用並保護人工智慧和其他現代工作負載的方式。 這項前所未有的創新,加上思科近期宣布的利用乙太網路交換、晶片和算力產品組合加速人工智慧基礎設施建設,以及與NVIDIA公司的合作,思科進一步拓展了能為防守方所提供的安全支持 。

    Hypershield能夠在客戶需要的任何地點提供保護,包括公有和私有資料中心、雲端平台和實體位置中的應用程式、裝置和資料。 Hypershield將人工智慧需求考慮在內,進行設計和構建,旨在幫助企業實現超越人力所能及的安全成果。

    Cisco Hypershield是思科有史以來最重大的安全創新之一。 思科在資料、安全、基礎架構和視覺化平台的實力,都令我們在協助客戶充分發揮人工智慧潛能方面具有得天獨厚的優勢。

    ——羅卓克

    思科董事長

    兼首席執行官

    Hypershield是一種革命性的全新安全架構。 它採用的技術最初僅針對超大規模公有雲;現在,則拓展為可供各種規模的企業IT團隊使用。

    Hypershield更像是一種安全網絡,而不僅僅是安全屏障,它使安全策略得以部署到任何需要它的地方。 無論是資料中心內的每個應用服務、公有雲中的每個Kubernetes集群,或是每個容器和虛擬機器(VM),Hypershield都能為其提供保護。

    Hypershield甚至將每個網路連接埠轉變為高效能的安全執行點,為雲端、資料中心、工廠車間或醫院影像室帶來全新的安全保障。 這項新技術能夠在幾分鐘內阻斷應用漏洞,並迅速阻止其橫向移動。

    AI有潛力使全球80億人擁有與800億人相同的影響力。 在這個充滿無限可能的時代,我們必須重新構想資料中心的角色,也就是資料中心的連結方式、安全保障、營運模式和擴展能力。 Cisco Hypershield的強大之處在於,它可以在任何需要的地方提供安全性,無論是軟體、伺服器,還是未來的網路交換器。 當您擁有一個包含數十萬個安全執行點的分散式系統時,簡化管理至關重要。 我們需要以更低成本實現更高等級的自動化。

    ——Jeetu Patel

    思科全球執行副總裁

    安全與協作事業部總經理

    Hypershield的安全執行分為三個不同的層次:軟體、虛擬機器以及網路和算力伺服器與設備,並利用了在高效能運算和超大規模公有雲中廣泛使用的強大硬體加速器。
    Hypershield基於三大支柱構建:

    三大支柱

    ●人工智慧原生:Hypershield以自動化和可預測為核心進行設計,一旦建立信任,Hypershield就可以實現自我管理,實現規模化的高度離散佈局。

    ● 雲端原生:Hypershield基於開源eBPF(Extended Berkeley Packet Filter)構建,是聯接和保護超大規模雲端雲端原生工作負載的預設機制。 思科預計將在本月完成為企業提供eBPF的領先供應商Isovalent的收購。

    ● 超分散式:思科正在徹底改變傳統網路安全性的工作方式,將高階安全控制嵌入伺服器和網路架構中。 Hypershield涵蓋所有的雲端平台,並利用資料處理單(DPU)等硬體加速功能來分析和回應應用程式和網路行為中的異常,為更需要保護的工作負載提供更強安全保護。

    憑藉在網路、安全以及廣泛的合作夥伴生態系統方面的業界領先專業知識,思科致力於與NVIDIA共同建構和優化人工智慧本地安全解決方案,以保護和擴展未來的資料中心。

    這項合作包括利用NVIDIA Morpheus人工智慧網路異常檢測框架,加速網路異常檢測,以及利用NVIDIA NIM微服務,為企業提供客製化的安全人工智慧助理。

    NVIDIA的整合式加速器系列產品結合了GPU和DPU運算的力量,保障了Cisco Hypershield從雲端到邊緣的強大安全性。

    各行各業的企業都在尋求能夠保護他們免受不斷擴大的網路威脅的安全解決方案,思科與NVIDIA共同利用人工智慧的力量,提供強大而極其安全的資料中心基礎設施,將幫助企業轉型並造福 全球客戶。

    ——Kevin Deierling

    NVIDIA網絡

    資深副總裁

    作為一項革命性的全新安全架構,Hypershield正在解決當今複雜威脅環境下客戶面臨的三大關鍵挑戰:

    三大關鍵挑戰

    ●分散式漏洞防禦:攻擊者擅長利用新發布的漏洞進行攻擊,其速度往往快於防守方進行修補程式更新的速度。 根據思科Talos威脅情報的數據,防守方每天幾乎要面對100個新的漏洞,可能導致災難性的後果。 Hypershield透過自動測試和部署補償控制措施到分散式執行點結構中,在幾分鐘內提供保護。

    ● 自主分段:一旦攻擊者進入網絡,分段就是阻止其橫向移動的關鍵。 Hypershield持續觀察、自動推理和重新評估現有策略,以自主地對網路進行分段,從而在大規模複雜環境阻隔攻擊。

    ● 自動驗證升級:Hypershield利用雙層資料平面,自動化了測試和部署升級的極為繁瑣和耗時的流程。 這種全新的軟體架構允許將軟體升級和策略變更放置在數位孿生中,並利用客戶獨特的流量、策略和功能組合進行測試,繼而在零停機情況下進行更新。

    Cisco Hypershield是思科人工智慧驅動的統一跨網域安全平台安全雲端(Security Cloud)的一部分,預計2024年7月全面上市。

    隨著思科完成對網路安全軟體公司Splunk的收購,客戶能夠在完整數位化足跡中獲得卓越的可見度和洞察力,從而獲得前所未有的安全保護體驗。

    AI不僅是向善的力量,也被用於不法目的,讓駭客能夠逆向工程補丁並在極短時間內創建漏洞利用。 思科希望透過AI解決方案來解決AI帶來的問題,因為Cisco Hypershield旨在透過幾分鐘內保護新漏洞不被利用,從而讓防守方重新獲得優勢,而不是等待補丁實際部署所需的數天、 數週甚至數月。 隨著漏洞數量的不斷增加,攻擊者大規模利用這些漏洞的時間也不斷縮短,顯然僅靠修補程式已無法跟上這一趨勢。 像Hypershield這樣的工具對於應對日益狡猾的惡意網路攻擊來說至關重要。

    ——Frank Dickson

    IDC安全與信任部門

    集團副總裁
    Cisco Hypershield旨在解決現代、AI規模資料中心所面臨的複雜安全挑戰。 思科對於能夠無縫整合從網路到終端的自我管理網路架構的願景,將有助於重新定義大規模安全的可能性,例如,在超分散式環境中實現這種層級的可見性和控制,能夠 防止攻擊者的橫向移動,這得益於一種自主且高度有效的獨特分段方法。 儘管這聽起來可能有些不可思議,但鑑於近期AI的進步以及eBPF等雲端原生技術的成熟,此刻正當時。

    ——Zeus Kerravala

    ZK研究創辦人

    兼首席分析師

    在AHEAD,我們堅信網路安全應該融入我們所做的一切。 附加的安全措施成本更高,效果更差,Cisco Hypershield確保網路安全防護融入企業架構之中。 分散式漏洞保護將為網路安全中的防守方帶來巨大勝利——傳統的合成修補程式主要局限於邊緣設備,一旦攻擊者突破邊界,就允許其進行橫向移動。 這對網路防守方來說,真是個好消息!

    ——Steven Aiello

    AHEAD

    首席資訊安全官

    思科(NASDAQ:CSCO)是全球科技領導廠商,致力於安全地連接一切,使一切成為可能。 我們的目標是透過重新定義應用、賦能混合辦公、保護企業安全、基礎架構轉型,幫助客戶實現永續發展目標,為所有人打造一個包容性的未來。 您可以在cisco.com.cn上獲取更多信息,並關注我們的微信公眾號“思科聯天下”。

    思科和思科標誌是思科或其附屬機構在美國和其他國家地區的商標或註冊商標。 您可以查看Cisco商標清單www.cisco.com/go/trademarks,其中提及的第三方商標是其各自所有者的財產。 使用「夥伴」一詞並不能直接表示思科與任何其他公司之間有合作關係。

  • 連接埠鏡像

    通信弱電交流學習

    連接埠鏡像
    通信弱電交流學習

    什麼是連接埠鏡像?

    連接埠鏡像是指在交換器或路由器上將經過指定連接埠(來源連接埠)的資料封包複製一份到另一個指定連接埠(目標連接埠)上,以實現網路流量的分析與監控。

    一些對即時監控比較注重的用戶在網路遭受了各種攻擊,需要檢查流量而不希望影響原來的網路時,可以利用連接埠鏡像,例如我國文化部和公安部要求網路服務場所安裝監控軟體,透過連接埠 鏡像採集相關數據,分析使用者的網路使用。

    依照工作範圍的劃分,連接埠鏡像分為兩種類型,本地鏡像和遠端鏡像。

    本機鏡像實作在同一台網路設備上,監控設備對客戶端的資料分析監控。

    遠端鏡像實現跨網路設備時,監控設備對客戶端的資料分析監控。

    連接埠鏡像的原理是什麼?

    本機連接埠鏡像的來源連接埠與目標連接埠處在同一台裝置上。

    如下圖所示,透過本機連接埠鏡像,來源連接埠(Eth 1/1)的資料封包被鏡像到目標連接埠(Eth 1/2)上。

    這樣連接在目標連接埠上的監控設備就可以對經過來源連接埠的資料封包進行監控分析。

     

    遠端連接埠鏡像的來源連接埠與目標連接埠處在不同的設備上,如下圖所示。

    透過遠端鏡像,來源連接埠(Eth 1/3)的資料封包經過兩台裝置的級聯連接埠(Eth 1/4)後被鏡像到目標連接埠(Eth 1/3)上,該連接埠將鏡像資料報 文複製到監控設備上,實現跨裝置的資料報文監控分析。

    端口鏡像的熱點問答

    交換器如何配置連接埠鏡像?

    設定連接埠鏡像的前提是交換器或路由器支援連接埠鏡像功能。 您可以根據需求場景選擇配置本機鏡像還是遠端鏡像。

    本機鏡像的設定步驟如下:

    1、建立VLAN

    2、將連接埠加入到VLAN中

    3、配置IP位址

    4.在目標連接埠下進行鏡像指令配置,將來源埠的資料封包鏡像到目標埠。

    遠端鏡像的設定步驟如下:

    1.在全域模式下建立來源端口

    2、配置一台交換器uplink端口

    3.在全域模式下建立目標端口

    4.設定另一台交換器uplink端口

    需要注意的是:
    1、在本機鏡像中,必須選擇一個口作為來源端口,一個口作為目標端口,配置才能生效

    2.如果需要建立鏡像組,一個鏡像組只能有一個目標端口,可有多個來源端口

    3.如果某個端口已經是鏡像群組的來源端口,則不能成為另一個鏡像群組的成員端口

    4.如果某個端口已經是鏡像群組的目標端口,則不能成為另一個鏡像群組的成員端口

    5.建議不要在目標連接埠上使用STP、RSTP或MSTP,否則會影響設備的正常使用

    連接埠鏡像與串流鏡像有什麼區別?

    連接埠鏡像與串流鏡像都屬於鏡像功能。

    每個網路連線都有入口流、出口流兩個方向的資料流,對交換器來說這兩個資料流需要分開鏡像。

    流鏡像是指按照一定的資料流分類規則對資料進行分流,然後將屬於指定流的所有資料鏡像到監控端口,以便進行分析。

    流鏡像可以透過存取控制清單(ACL)的方式匹配合適的流,也可以透過指令匹配,在功能上比連接埠鏡像更強大。

    連接埠鏡像與連接埠對映有什麼區別?

    連接埠對映是指將內部網路的某個(LAN)IP位址轉送到公網路上,或將外網的(WAN)IP位址轉送到內網路上。

    例如有一台電腦本地的IP位址是192.168.1.10,在這台電腦上用百度查詢資料,資料傳輸的流程是:

    透過路由器用ADSL撥號上百度,百度只能辨識到路由器的IP位址,把資料傳給路由器後,路由器透過內建的連接埠對映表(設定了連接埠對映路由器才能準確辨別訊息應回傳給哪個本機IP)把 數據返回電腦。

    連接埠鏡像與連接埠對映的主要區別在於:連接埠鏡像是流量複製的過程,連接埠映射是流量轉送的過程。
    如何驗證連接埠鏡像是否成功?
    通常情況下,你可透過流量抓包軟體進行流量抓包驗證,在監控裝置上進行抓包測試,如果可以取得到來源埠發送或接收的資料包,則連接埠鏡像成功。

    主流廠商交換器埠鏡像配置
    華為
    配置 GigabitEthernet0/0/1 為鏡像接口,GigabitEthernet0/0/2 為觀察接口,觀察接口索引號為 1。 鏡像 GigabitEthernet0/0/1 上的雙向業務流量到 GigabitEthernet0/0/2 上。

    system-view

    [Quidway] observe-port 1 interface gigabitethernet 0/0/2

    [Quidway] interface gigabitethernet 0/0/1

    [Quidway-GigabitEthernet0/0/1] port-mirroring to observe-port 1 both

    步驟 1 執行指令 system-view,進入系統視圖

    步驟 2 執行指令 observe-port index interface interface-type interface-number ,設定觀察接口

    步驟 3 執行指令 interface interface-type interface-number,進入鏡像介面的介面視圖

    步驟 4 執行指令 port-mirroring to observe-port index { both | inbound | outbound } ,設定介面鏡像

    華三

    配置 GigabitEthernet0/0/1 為鏡像接口,GigabitEthernet0/0/2 為觀察接口,觀察接口索引號為 1。

    鏡像 GigabitEthernet0/0/1 上的雙向業務流量到 GigabitEthernet0/0/2 上。
    system-view

    [sysname] mirroring-group 1 local

    [sysname] mirroring-group 1 mirroring-port G0/0/1 both

    [sysname] mirroring-group 1 monitor-port G0/0/2

    步驟 1 執行指令 system-view,進入系統視圖
    步驟 2 執行指令 mirroring-group number local ,建立一個鏡像群組

    步驟3 執行指令mirroring-group 1 mirroring-port G0/0/1 { both | inbound | outbound },將連接埠加入到鏡像群組中,鏡像可以根據實際情況靈活選擇入方向、出方向及全部流量;both, 全部流量;inbound,入方向流量;outbound,出方向流量

    步驟 4 執行指令 mirroring-group 1 monitor-port G0/0/2 ,設定鏡像的目的連接埠。

    銳捷

    配置 fa0/1 為鏡像接口,fa0/2 為觀察接口,觀察接口索引號為 1。 鏡像 fa0/1 上的雙向業務流量到 fa0/2 上。

    Switch# configure terminal

    Switch(config)#monitor session 1 source interface fa0/1 both

    Switch(config)#monitor session 1 destination interface fa 0/2

    步驟 1 執行指令 configure terminal,進入全域設定模式

    步驟2 執行指令monitor session 1 source interface fa0/1 { both | inbound | outbound } ,建立觀察介面索引號為1,並將fa0/1 加入此索引,鏡像可依實際情況靈活選擇入方向、出方向及 全部流量;both,全部流量;inbound,入方向流量;outbound,出方向流量

    步驟 3 執行指令 monitor session 1 destination interface fa 0/2 設定 fa0/2 為監控口。
    思科
    配置 fa0/1 為鏡像接口,fa0/2 為觀察接口,觀察接口索引號為 1。 鏡像 fa0/1 上的雙向業務流量到 fa0/2 上。

    Switch# configure terminal

    Switch(config)# monitor session 1 source interface fastethernet 0/1 both

    Switch(config)# monitor session 1 destination interface fastethernet 0/2

    步驟 1 執行指令 configure terminal,進入全域設定模式

    步驟2 執行指令monitor session 1 source interface fa0/1 { both | inbound | outbound } ,建立觀察介面索引號為1,並將fa0/1 加入此索引,鏡像可依實際情況靈活選擇入方向、出方向及 全部流量;both,全部流量;inbound,入方向流量;outbound,出方向流量

    步驟 3 執行指令 monitor session 1 destination interface fa 0/2 設定 fa0/2 為監控口

  • Microsoft:我們不會為了 Rust 而「放棄」C#

     21CTO

    儘管最近有關於微軟減少其自家C#語言的使用,以支持Rust語言的消息不斷傳出,但這家公司表示它仍然致力於支持C#。

    這項消息來自MSPoweruser的Rafly Gilang看到微軟的招募訊息,它在尋找熟悉Rust的架構師幫助在Rust中重寫使用C#(.net序列中的程式語言)建構的核心元件。

     

     

     

     

     

     

     

     

    網址:https://jobs.careers.microsoft.com/global/en/job/1633482/Principal-Software-Architect

    其職位描述是指導現有大規模 C# 雲端服務向 Rust 程式碼的技術過渡。 此舉被視為是Microsoft採用Rust實現全球平台服務現代化和優化的更廣泛努力的一部分。 Rust 語言提供記憶體安全性和效能。

    C# 不會無處可去

    Microsoft承認它對 Rust 的各種用例感興趣,但 C# 不會被取代。 相反,Rust 只是該公司武器庫中的語言。

    微軟的發言人這樣說:

    「在 Microsoft,我們使用各種程式語言來開發並向客戶交付產品和服務。C#仍然是Microsoft高度重視的語言,我們致力於其持續成長和發展」。

    C#是一種通用的高階程式語言,由Anders Hejlsberg設計。 Anders Hejlsberg是Microsoft「自吹自擂「的技術研究員、軟體工具製造者和程式語言創作者。 Microsoft 於 2000 年發布了 C#。

    而 Rust 是一種多範式、通用的程式語言,強調效能、類型安全性和並發性。 Rust 於 2015 年問世,被視為一種更現代的程式語言。 Rust 基金會是此程式語言的管理者。

    Rust基金會的一位代表說:

    「因為Microsoft是Rust基金會白金會員的創始成員,我們的團隊自成立以來一直致力於Rust程式語言的發展和未來的成功。儘管如此,我們並不認為Microsoft對Rust 的承諾表明C# 被’放棄’ ,正如最近的報導和評論所暗示的那樣。

    Microsoft尋求填補的職位角色是該公司的Substrate App Platform小組,該開發小組是Microsoft 365核心平台開發團隊的一部分。

    」生鏽的愛「

    如今,Rust 程式設計師的需求開始變得很大,因為越來越多的組織因其安全性和效能而轉向該語言。

    Omdia分析師Brad Shimmin說:

    「這就像人們在說『嘿,我們為什麼要用Rust 重寫Linux 核心的一部分?』這些都是挺大的問題,因為與Python之類的東西相比,Rust對開發者並不友好,但 作為一種通用語言,與C語言相比,它有一些重要的優勢。

    Rust 在最新的流行程式語言 TIOBE 排行榜中排名第 18位,而 C# 排名第5。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    同時,2023 年 Stack Overflow 調查將 Rust 列為最受推崇的語言,因為去年使用它的開發人員中有超過 80% 希望今年再次使用它。 2022 年 Stack Overflow 調查報告顯示了 Rust 的類似結果。

    Brad Shimmin也說:

    「你可以編寫與C# 一樣快的裸機程式碼,而不必擔心伴隨該語言的記憶體’陷阱’,我認為對於更廣泛的應用程式中的特定項目和模組,Rust 絕對是一個不錯的選擇,尤其是在 效能和健壯性被提上日程的情況下。 發行版一樣。

    事實上,就性能和健壯性而言,Rust 是一個不錯的選擇。

    「我想這是一種更好、更有效的編碼和管理資源的方式——Rust 的價值在於它是被編譯的,它管理內存,而不是C++,你管理內存(安全問題),但它很 快,C# 管理記憶體(垃圾收集器),但它是字節碼動態編譯,沒有那麼快或節省空間,“

    Rust 管理記憶體(新格式,而不是垃圾回收器),並且對其進行編譯,使其更快、更有效率。 這主要對在 Office 365 等雲端平台上運行的東西有價值。

    關於預算

    針對Microsoft 經常修改Azure中執行的服務代碼。 微軟MVP和區域總監,Campbell&Associates的創辦人Richard Campbell這樣表示:

    「我懷疑他們熱衷於優化該程式碼,因為這會花掉他們部門的預算」。

    Campbell 指出,這些程式碼最初是用 C# 編寫的,因為可以快速開發並進入市場——只有當它變得熱門時,才會考慮 Rust 可以帶來的那種極端的效能最佳化。 只有當服務需求量很大時,微軟才會考慮這種優化——如果很少人使用它,那就不值得了。

    「當你追求峰值最佳化時,你會傾向於使用低階語言——那種『接近金屬』的語言,這樣你就可以盡可能地節省每一個處理週期。C# 是一種很棒的語言,但它 存在於託管運行時中,該運行時針對可靠性和易用性進行了優化。 – 通常是C++。

    而相關的權衡是,C++程式碼更難編寫和調試,並且需要非常熟練的人來編寫高度優化的程式碼。

    Campbell 說:「Rust 代表了新一代的低階程式語言,它使得在該層級創建高品質的程式碼變得更加容易。

    一個錯誤?

    然而,對於一家軟體公司來說,僅僅用 Rust 重寫其程式碼庫可能是一個錯誤。

    Brad Shimmin這樣說:

    「首先,有能力的 Rust 開發人員比那些精通 C#、React 等工程師更難找到,其次,如果出現大規模的變化,Rust 中的一些記憶體安全限制可能會隨著時間推移而變得難以維護。

    但是,他說可以很容易想像Microsoft為什麼要這樣做。

    「這與 Linus Torvalds 允許 Rust 進入 Linux 核心的理由相同:效能和穩定性,」這就是 Linus 從驅動程式開始的原因。 它們就在祼機金屬上工作,而且是高度模組化的。 用Rust很合適。 就像用 Python 編寫Web應用程式一樣,它也非常適合資料科學專案。

    Google 也提高了 Rust 賭注

    同時,Microsoft並不是唯一一家密切關注 Rust 的大公司。 如果你關注21CTO,本月早些時候,Google承諾向Rust基金會提供100萬美元,以提高C++和Rust程式語言之間的互通性。 (相關連結:Google向 Rust 基金會捐贈 100 萬美元,改善 Rust 與 C++ 的互通性)

    雖然這個專案被稱為“Interop Initiative”,但其目標本質上更加聚焦,讓“組織慢慢地將當前的C++遷移到Rust”。

    同樣的情況,關注記憶體安全是一個核心問題。

    Lars Bergstrom 在Ggoogle 是 Android 平台工具和函式庫的總監,也是 Rust 基金會董事會主席。 他在一篇部落格文章中這樣寫道:

    “雖然 Rust 可能不適合所有產品應用程序,但優先考慮與 C++ 的無縫互通性將加速更廣泛的開發者社區採用,從而與提高內存安全性的行業目標保持一致,”

    作為具有網路安全背景和基礎設施安全局 (CISA)的 局長 Jen Easterly 最近倡導在 Android 中使用 Rust 和 Google 核心的實現,作為組織和平台緩解記憶體安全漏洞的關鍵方式。 據CISA稱,大約三分之二的已知軟體漏洞是一類被稱為「記憶體安全」漏洞的弱點,這些漏洞是引入了與電腦記憶體存取方式相關某種類型的漏洞。

    此外,Google一直是 Rust 實施的先驅。 谷歌表示,迄今為止,在 Android 的 Rust 程式碼中發現的記憶體安全漏洞為零。 雖然Google在Android中使用Rust的成長最為明顯,但該公司仍在繼續擴大其在更多應用程式中的使用,包括客戶端和伺服器硬體。

    Microsoft 的「生鏽」歷史

    事實上,Microsoft對 Rust 的興趣已經不是一兩天了。

    早在 2020 年,微軟就表示逐步轉向 Rust 來建立其基礎設施軟體,遠離 C/C++。

    2022 年,Azure 技術長Mark Russinovich 就在Twitter(現在稱為X)上發文說:「說到語言,是時候停止在C/C++ 中啟動任何新專案了,並將Rust 用於需要非GC 語言 的場景。

    雖然然 Rust 的學習曲線很陡峭,Azure團隊更喜歡 Rust 而不是 Go,因為 Rust 能夠發現 Go 無法發現的錯誤。

    去年,Russinovich 在平台上發文說:“如果你在 Windowns 11 Insider 體驗頻道上,你就會在 Windows 核心中第一次嚐到 Rust 的滋味!”

     

  • 平台工程如何應對DevOps挑戰

    岱军 云云众生s

    一覽 DevOps 的核心挑戰,以及平台工程是否可能取而代之。

    譯自How Platform Engineering Takes on DevOps Challenges,作者 Kenn Hussey。

    隨著公司持續以前所未有的速度擴展,DevOps 的角色正在經歷重大轉型。 雖然 DevOps 一直是彌合開發和維運之間差距的重要工具,但其局限性和低效率也變得越來越明顯。

    許多人認為平台工程是 DevOps 的自然演進,它解決了 DevOps 的核心挑戰,並使組織更有效地擴展。 隨著重點轉向創建自助服務平台和賦能開發人員,DevOps 的傳統角色正在被重新定義。

    讓我們回顧一下 DevOps 的核心挑戰以及平台工程如何取代它。

    雖然 DevOps 徹底改變了軟體開發和部署,但現代雲端原生技術的日益複雜性給團隊帶來了前所未有的壓力。 隨著組織的擴展,目前 DevOps 方法的限制和低效率變得更加明顯。

    一個主要挑戰是需要在端到端 DevOps 流程中實現更多自動化。 Dynatrace 最近關於 DevOps 自動化的研究顯示,只有 56% 的這些流程是自動化的,導致交付時間更長,效率降低。 在典型的開發人員管道中平均有九項手動幹預,包括審批和安全檢查,這進一步加劇了這種情況。 這些導致了解決時間延長,並可能嚴重影響組織的利潤和客戶滿意度。

    造成這種情況有兩個核心原因。 第一個是工具鏈的複雜性。 DevOps 生態系統中豐富的工具和技術可能導致難以管理的碎片化環境。 這種複雜性為團隊整合和維護一個有凝聚力的 DevOps 工作流程帶來了挑戰,導致效率低下和生產力下降。

    第二個是孤島團隊。 孤島會阻礙協作和溝通,而協作和溝通對於成功採用 DevOps 至關重要。 孤島團隊通常缺乏對彼此流程的可見性,導致錯位、重複工作和問題解決時間更長。

    即使沒有這些問題,團隊也缺乏推動自主營運的關鍵技能,這使得有效實施和維護 DevOps 實踐變得具有挑戰性。 所需的技能,包括編碼、基礎設施管理和自動化,在單一團隊中可能很難找到和培養。

    隨著目前 DevOps 方法的限制變得越來越明顯,組織正在尋求克服這些挑戰並改善其軟體交付流程的方法。 DevOps 團隊必須縮短開發週期以實現業務服務等級目標 (SLO),提高軟體品質並更快地創新。 平台工程應運而生。

    什麼是平台工程?
    平台工程是 DevOps 的一種現代方法,更確切地說,是 DevOps 的一個邏輯擴展,旨在與現有的 DevOps 原則一起工作,同時減輕相關的認知負擔。 平台工程師透過建立內部開發人員平台(IDP)來簡化標準 DevOps 活動,該平台提供單一的應用程式開發和部署工具包。

    作為 DevOps 的策略擴展,平台工程解決了傳統手動方法的缺點、不足和限制。 它自動化了開發和部署管道,簡化了它們以提高效率和有效性,超越了傳統限制。 採用平台工程文化使企業能夠在數位轉型時代脫穎而出,讓他們能夠在當今瞬息萬變的技術環境中蓬勃發展。

    平台團隊可以簡化和提高先前由 DevOps 團隊處理的任務的效率。 你的平台團隊必須有明確定義的產品目標、已建立的 DevOps 程式和正確的思維方式才能發揮其潛力。

    在新科技時代,平台工程師的角色並沒有取代 DevOps,而是擴展了使其成功應對新挑戰和機會的原則。 平台工程將在軟體開發和交付中發揮重要作用。

    平台使 DevOps 能夠大規模擴展
    隨著 DevOps 的興起極大地改變了軟體開發,使其變得更加敏捷和協作,但組織通常需要幫助才能獨立處理複雜性。 平台工程源於為開發人員提供簡單、可擴展且用戶友好的自助服務流程以更快地建立軟體的需求。

    組織可以利用平台工程來:

    簡化流程:透過提供標準化、簡化的軟體開發和部署方法來簡化複雜流程。

    自動化基礎設施和部署:自動化是平台工程的核心,使團隊能夠在最少的手動幹預下配置基礎設施和部署應用程式。

    提供自助服務平台以提高開發人員效率:自助服務平台使開發人員能夠快速輕鬆地存取他們需要的工具和資源,而無需依賴其他團隊或等待批准。

    縮短上市時間:透過簡化流程和自動化任務,平台工程幫助組織更快、更頻繁地交付軟體。

    提高可擴展性和彈性:平台工程使組織能夠建立可擴展且有彈性的系統,這些系統可以處理增加的需求並從故障中快速恢復。

    促進協作:平台工程透過提供一個共享平台和一套通用的工具和實踐來促進協作,使團隊能夠更有效地協同工作。

    平台工程可以幫助團隊快速擴展他們目前的 DevOps 流程來滿足需求,而無需引入不必要的開銷。 平台工程不是依賴單獨的工具,而是建構了一個支援端到端交付的緊密基礎。

    任何平台工程團隊的主要目標是促進工具和配置重用。 重複使用程式碼可以使應用程式交付過程更有效率,需要的工具更少,並且可以改善程式碼一致性。 開發人員可以專注於創新,而不是編寫重複的程式碼。

    平台工程如何優化 DevOps 效率
    軟體開發團隊的需求通常不同。 如果每個開發團隊都建立自己的 DevOps 實踐,您將遇到複雜性、瓶頸和安全漏洞。 平台工程團隊可能會承擔部分 DevOps 職責,例如以下職責:

    自動化 Git 工作流程:平台團隊可以自動化 git 儲存庫的建立、配置和管理,確保整個組織的一致且安全的版本控制實務。

    配置測試環境:透過自動化測試環境的配置,平台團隊可以減少設定和維護測試基礎架構所需的時間和精力。

    為 CI/CD 管道建立配置模板:平台團隊可以為 CI/CD 管道建立可重複使用的模板,使開發團隊能夠快速採用最佳實踐並在專案中保持一致性。

    配置用於秘密管理和使用者身份驗證的中央儲存庫:集中這些功能有助於維護安全性並符合要求,同時簡化開發團隊的存取控制。

    配置用於應用程式效能監控的儲存庫:平台團隊可以設定和維護一個用於應用程式效能監控的集中儲存庫,該儲存庫可為開發人員提供對其應用程式行為和效能的見解。

    以下是您的平台團隊如何優化 DevOps 效率的方法:

    為內部開發人員建立一個工作平台:透過創建一個標準化的自助服務平台,平台團隊可以簡化開發流程並減輕各個團隊的負擔。

    建立鋪設好的道路以減少認知負荷:鋪設好的道路為常見的開發任務提供了預先定義的、經過充分測試的路徑,從而減少了開發人員的認知負荷並最大程度地降低了錯誤風險。

    簡化流程、標準化流程並擴展流程:平台團隊可以識別並簡化複雜流程,制定標準並確保隨著組織的發展,這些流程可以有效地擴展。

    監控關鍵績效指標 (KPI) 和指標:透過此監控,平台團隊可以識別需要改進的領域,並做出數據驅動的決策以優化 DevOps 效率。

    提升團隊績效,為客戶提供更大價值:平台團隊可以持續評估並提升開發團隊的績效,最終為客戶提供更好的價值。

    以下是貴組織吸引合適的工程師加入平台團隊的關鍵策略。

    明確目標並定義現實的時間表:明確傳達平台團隊的目標和期望,並設定可實現的時間表,有助於吸引與組織願景一致的工程師。

    擁抱多元化,促進更好的溝通與協作:培養一個多元化和包容性的團隊環境,可以促進平台工程師之間的創造力、創新和實際合作。

    為平台團隊提供合適的工具和技術:為平台團隊配備必要的工具和技術,使他們能夠有效率且有效地工作,吸引重視良好支援工作環境的熟練工程師。

    DevOps 的未來在於採用平台工程,而不是傳統的孤島式實踐。 為了在當今瞬息萬變的環境中保持競爭力,組織必須將平台工程作為 DevOps 之旅的下一步。 它將塑造團隊協作、整合和簡化未來軟體交付的方式。

    隨著 DevOps 的發展,平台工程將促進無縫的跨團隊溝通並優化工作流程。 透過自助功能和自動化管道,軟體更新將更快完成,從而取代手動任務。

    從 DevOps 過渡到平台工程可能是快速變化的 IT 產業中的下一個規範。 一個引人注目的可能性是,新的平台有一天可能會結合併協調當代數位環境的所有複雜性。 在當今快速發展的數位世界中,能夠隨時代變化而改變的人才能保持領先地位。

  • LPIC-1 Exam 101 Objectives

    Exam Objectives Version: 5.0

    Exam Code: 101-500

    關於目標權重:每個目標都分配有一個權重值。 權重表示考試中每個目標的相對重要性。 考試中將涵蓋權重較高的目標,並包含更多問題。

    Topic 101: System Architecture

    101.1 Determine and configure hardware settings

    Weight 2
    Description Candidates should be able to determine and configure fundamental system hardware.

    Key Knowledge Areas:

    • Enable and disable integrated peripherals.
    • Differentiate between the various types of mass storage devices.
    • Determine hardware resources for devices.
    • Tools and utilities to list various hardware information (e.g. lsusb, lspci, etc.).
    • Tools and utilities to manipulate USB devices.
    • Conceptual understanding of sysfs, udev and dbus.

    The following is a partial list of the used files, terms and utilities:

    • /sys/
    • /proc/
    • /dev/
    • modprobe
    • lsmod
    • lspci
    • lsusb

     

    101.2 Boot the system

    Weight 3
    Description  Candidates should be able to guide the system through the booting process.

    Key Knowledge Areas:

    • Provide common commands to the boot loader and options to the kernel at boot time.
    • Demonstrate knowledge of the boot sequence from BIOS/UEFI to boot completion.
    • Understanding of SysVinit and systemd.
    • Awareness of Upstart.
    • Check boot events in the log files.

    The following is a partial list of the used files, terms and utilities:

    • dmesg
    • journalctl
    • BIOS
    • UEFI
    • bootloader
    • kernel
    • initramfs
    • init
    • SysVinit
    • systemd

     

    101.3 Change runlevels / boot targets and shutdown or reboot system

    Weight 3
    Description Candidates should be able to manage the SysVinit runlevel or systemd boot target of the system. This objective includes changing to single user mode, shutdown or rebooting the system. Candidates should be able to alert users before switching runlevels / boot targets and properly terminate processes. This objective also includes setting the default SysVinit runlevel or systemd boot target. It also includes awareness of Upstart as an alternative to SysVinit or systemd.

    Key Knowledge Areas:

    • Set the default runlevel or boot target.
    • Change between runlevels / boot targets including single user mode.
    • Shutdown and reboot from the command line.
    • Alert users before switching runlevels / boot targets or other major system events.
    • Properly terminate processes.
    • Awareness of acpid.

    The following is a partial list of the used files, terms and utilities:

    • /etc/inittab
    • shutdown
    • init
    • /etc/init.d/
    • telinit
    • systemd
    • systemctl
    • /etc/systemd/
    • /usr/lib/systemd/
    • wall
  • SPRING和JAVA如何塑造內部開發者平台

     岱军 云云众生s

    Java 和 Spring 為開發過程帶來的靈活性,影響了目前 IDP 實作標準化和效率的方式。

    譯自How Spring and Java Shaped Internal Developer Platforms,作者 Charles Humble。

    我早就注意到Java促進了編寫程式碼的異常一致的方法。 該語言的表面積相對較小,幾乎沒有粗糙的邊緣,這使得開發人員從一個 Java 專案遷移到另一個專案非常簡單。 對於建構或維護內部開發者平台(IDP) 的任何人來說,教訓是促進一致性真的很重要。

    雖然這始終適用於 Java SE,但並不總是適用於其擴充功能。 如今,企業 Java 開發人員有許多優秀的框架可供選擇,但有一定年齡的人可能還記得在 2000 年代初使用 J2EE 進行程式設計的情況。 J2EE 標準於 1999 年底推出,它使用 Web 和分散式企業應用程式規格擴展了 Java SE,這些應用程式可以部署在諸如 BEA WebLogic 或IBMWebSphere 等應用程式伺服器上。

    J2EE 標準被廣泛採用,但因難以使用而聲名狼藉。 該規範的某些部分,尤其是 IBM 開發的原始企業 JavaBean (EJB) 規範,確實很複雜,並且帶來了相當大的效能損失。 例如,EJB 僅允許透過諸如公共物件請求代理體系結構 (CORBA) 等協定進行遠端方法調用,這與大多數其他業務應用程式形成對比。

    此外,當時設計的應用程式伺服器可以啟動一次並在沒有中斷的情況下運行數月甚至數年。 正如 Java 冠軍Holly Cummins 所解釋的那樣,BEA、IBM 和其他支援完整 J2EE 規格的供應商做了一些非凡的工程工作來實現這一目標。 缺點是啟動它們(就像在開發程式碼時經常做的那樣)需要幾分鐘。 這使得開發人員難以保持流程;作為一名英國人,我過去每次必須重新啟動開發伺服器時都會泡一杯茶(並且經常喝掉),這似乎更多的提升了Twinings 的銷售,而不是我的 編碼效率。

    笨重、緩慢且昂貴
    此外,打包和部署用於生產的 J2EE 應用程式很麻煩。 「我參與其中,」DaShaun Carter解釋道,他是 VMware Tanzu(Broadcom 的一個部門)的研究開發軟體工程師和 Spring 開發人員倡導者。 當 Carter 在一家能源公司擔任 J2EE 開發人員時,他的職責是進行建造。 「當我開始時,構建需要一周時間,並且該規範有 12 個人將 J2EE 應用程式投入生產,」他說。 Carter 能夠使用 Apache Ant 和各種自訂外掛程式來縮小流程。 “我們處於每週構建和測試的周期中,但生成所有 WSDL [Web 服務描述語言文檔] 和構建應用程序仍然需要四個小時。”

    開發工具也很昂貴。 Carter 說,他們的一個工具,統一建模語言工具 Rational,每個席位需要 20,000 美元才能擁有每個開發人員所需的一切。 「這太荒謬了,」他說。

    Spring 的興起改變了範例
    2004 年推出的 Spring 框架做了一些重要的事情。 首先也是最重要的,它推廣了依賴注入的概念,其核心是控制反轉 (IoC) 容器。 它還表明,可以在諸如 Apache Tomcat 等更輕量級的 servlet 容器之上建立更簡單的 Web 和分散式應用程式。 這些應用程式啟動得更快,使開發人員能夠快速成功地開始工作,而且它們仍然是開源且免費的。 大約在同一時間,諸如 Eclipse 和 NetBeans 等開源整合開發環境 (IDE) 開始取代專有 IDE 產品,進一步降低了成本。

    Spring 還提供了一種使用 Java SE 提供的相同編碼一致性來建立企業應用程式的方法。

    不過它並不完美。 Spring 不幸的是在 XML 流行的高峰期開發的,它對 XML 的依賴造成了配置方面的問題。 隨著框架中添加了更多功能,Spring 也被認為過於複雜。

    2006 年在 Java SE 6 中採用註解作為 XML 的替代方案,在一定程度上幫助 Spring 團隊減輕了配置複雜性。 然而,最終最大程度地減少配置問題的,是受 Ruby on Rails 啟發的 Spring Boot,它提供了關於如何建立 Spring 應用程式的高度主觀視圖。

    IDP 如何減少摩擦
    Spring Boot 也透過 Initializr 和start.spring.io推動了模板化的想法。 「這是我了解 IDP 概念的開端,」Carter 說。 “我可以獲取我需要的東西,例如 Spring Data 和 Spring Web,並按需組合在一起。使用 IDP 方法,模式及其原因定義明確,因此它創造了良好的開發者體驗。”

    Initializr 提供了護欄,並允許開發者快速啟動並運行。 「我可以立即開始並期待快速交付,因為 IDP 提供了大量資訊和範例,例如我們如何處理日誌和指標等,」Carter 解釋說。

    在此背景下,IDP 充當傳播者,在公司內部傳播模式,打破孤島並減少摩擦。 正如VMware Tanzu 在Broadcom 的研究和開發高級總監James Watters所說,「它減少了安全性、架構和開發團隊之間的界限。」最終,目標是讓IDP 充當快速反饋、可組合性和模式擴散的真正 切入點,尤其是在大型組織中。

    以 Spring 為藍本的 IDP 降低了開發者的靈活性,但 Watters 借用雲端運算進行了類比,解釋了為什麼這可能是一件好事:

    「雲端運算在很大程度上減少了對第2 層網路的依賴。你無法自訂第2 層網絡,就像你可能在資料中心中所做的那樣。但你可以獲得一個可彈性使用的可 擴展模型。我認為帕累托效率適用於網絡,一直到應用程式模式,而這是IDP 擅長的領域。Cloud Foundry是模式力量的早期指標之一,我認為我們已經看到了許多其他模式的出現, 包括應用程式模板化、預設安全性和建立服務模板化。如果你考慮Google Cloud Run或Azure Container Apps,整個行業都開始表示模式是實現效率和預設安全性的非常好的方法。”

    此外,由於 Initializr 是開源的,並且在其下方有完整的 Spring 框架,因此組織可以根據其需求和文化進行調整。

    Garmin 如何使用模式和自動化
    消費性電子公司 Garmin 的私有雲平台架構師Jonathan Regehr表示,這是他們採取的方法。 作為黑客馬拉鬆的一部分,Garmin 建立了一個工具,最好將其描述為早期後台類型的門戶。 它會產生一個骨架程式碼庫並將其載入到 Git 儲存庫中。 它還會建立 Jenkins 作業,首次運行它並將應用程式骨架一直推送到生產環境,因此開發者只需編寫程式碼即可。 「這個笑話是,你填寫一份表格,小睡一會兒,醒來後就可以開始編碼了,」Regehr 說。

    他承認,該工具現在已經相當老了,他的團隊正在尋找替代品。 即便如此,這也展示了使用模板和自動化來入門的力量。 「如果你仔細考慮監聽器之類的內容,它就是一個模式。我不應該關心如何獲取事件或處理一致性;讓模式處理這些問題,我只需要監督業務價值部分,」Regehr 說。

    當工程師在團隊之間移動時,這種傳播模式的方法具有進一步的優勢,因為它提高了一致性。 正如Monzo Bank 的高級員工工程師Suhail Patel在2022 年解釋的那樣,「[在Monzo] 當你開始處理微服務時,有一條明確的鋪就道路,因此它們看起來都非常統一。你可以為其他團隊 的服務做出貢獻,因為該結構對你來說完全熟悉。”

    Regehr 也同意這個想法。 「我認為你不能指望把某人放到一個專案中,然後讓他們立即發揮作用。人們在加入團隊後會有一個學習曲線。但如果部署相同,程式碼庫看起來相同,並且所有內容的佈局相同 ,他們會說,’好的,我需要了解你的業務邏輯,但其他部分都很容易。’”

    可擴展性取決於決策
    Monzo 和 Garmin 也說明了在平台內做出選擇的重要性。 「建構平台團隊的大規模參與者往往有兩種到四種關鍵模式,」James Watters 說。 “他們概述瞭如何擴展 Java 服務或 Go 服務,而不是嘗試為開發人員可能擁有的每個打開的標籤頁構建一個門戶。這兩種方法非常不同。”

    Garmin 對叢集配置採取了類似的方法。 從語言和運行時角度來看,該環境是混合的。 Garmin 約 70% 的程式碼(Web 應用程式和偵聽器的混合)是用 Java 編寫的。 該公司也運行大量Node.js和 .NET,一些Python和少量 PHP。

    Garmin 運行兩個平台:Red HatOpenShift 用於 Kubernetes 工作負載,而 VMware Tanzu Application Service(部分客戶仍將其稱為Pivotal Cloud Foundry(PCF))用於其餘部分。 隨著數百名開發人員使用VMware Tanzu 平台,Garmin 在一個非生產環境和四個生產基礎上運行超過 9,000 個應用程式實例。 它使用多雲基礎設施,部分原因是收購,也運行一個大型私有雲。

    Regehr 的團隊完全在內部工作,他們遵循「自動化一切」的範例。 例如,為了管理他們的Kubernetes集群,他們編寫了 140,000 行自動化程式碼。 開發人員貢獻少量配置程式碼,並由此和他們的自動化產生所有必需的叢集配置,並將它們放入儲存庫中。

    「我們正在自動生成 110 萬行集群配置,Argo CD正在噴射和建立集群,」Regehr 說。 “我們使用生成存儲庫來執行此操作,這意味著如果我犯了一個錯誤,我可以查看錯誤並修復它,而不是集群因我而消失。”

    短暫基礎建設的優勢
    這種級別的自動化允許基礎設施團隊將所有內容視為短暫的。 「一個例子是Concourse,」Regehr 解釋說。 「我們有一個與每個Tanzu 平台部署配對的Concourse 實例,該實例處理特定於該基礎的自動化。如果Concourse 的磁碟空間用完或其資料庫損壞,解決方案始終相同——燒毀Concourse,運行自動化腳本重新 部署Concourse,然後運行我們的“UpdatePipeline”管道。這個Concourse 看起來與10 分鐘前完全一樣,除了減少了一些作業運行歷史記錄。”

    Regehr 說,採取這種方法也有助於 Garmin 提高安全性。 「如果你想讓駭客一無所獲,其中一種方法就是如此快速地重建你的基礎設施,即使他進入伺服器並構建了他的『邪惡框架』,它也會消失得如此之快,以至於他無法在 它再次消失之前重建它。”

    這可能對基礎設施有效,但程式碼本身呢? James Watters 說,“在我進行的對話中引起共鳴的頭號話題是:我們如何在規模化組織中默認變得更加安全?”

    James Watters 認為,開發者平台充當起點,提供標準化的應用程式模式和整合程式庫,讓你對應用程式進行身份驗證。 「我們還擁有一個預設安全的建置系統,該系統已重新註入 IDP,並且我們可以在創建應用程式的確切時刻提供快速的安全記分卡,」他說。 IDP 還可以向開發人員發出警報,例如,“你知道這個應用程式中存在漏洞並且有可用的修復程式嗎?你想應用它嗎?”

    VMware Tanzu 團隊正在探索人工智慧對產業的影響,其中一些工作已經透過Spring.ai可見。 James Watters 說他對人工智慧的重要性感到“震驚”,但他也看到了安全方面還有很多未完成的工作。 「做更多的事情來自動化安全任務並建立更多模式化和安全的系統,這是我們的客戶希望看到的,」他說。

     

  • 區域網路ip位址不夠用腫麼? 用這三種方法,可以完美解決?

    通信弱电交流学习

    如果是在一個小型的區域網路裡可能完全不必要考慮IP位址不夠的情況,但是在超過「255台」電腦的大型區域網路裡,就必須要考慮電腦IP位址不夠用該如何解決了。

    很多時候企業區域網路出現私網路位址192.168.1.x-255不夠用了,去掉一個廣播位址及一個網路位址後就可能不夠用。 (0是網路位址不可用, 255是廣播位址,除去這2個,可用的就是254個位址)。

    那麼如何解決呢?

    首先,我們來了解一下IP位址:“X.X.X.X”

    x代表0到255之間的任一個自然數,但是,在區域網路裡面,這裡的數字設定是有規則的,一般是由子網路遮罩來分割。

    如255.255.255.0。 說明最後面一個X可以從0到255之間隨意改變。 當網關是192.168.1.1時,我們可以設定成192.168.1.1–192.168.1.254。

    當在一個區域網路內,ip位址超過了數量怎麼辦,這個通常發生在C類的ip位址區域網路中較多,可以有三種方法來解決這個問題。

    一、改子網路遮罩

    因此當子網路遮罩設定成255.255.255.0時,路由器下面的區域網路最多只能”254台”電腦分配相對獨立的IP位址。

    想要增加區域網路IP,那麼可以修改下子網路遮罩就可以了,例如子網路遮罩從255.255.255.0修改成255.255.0.0,那麼我們區域網路裡面的電腦IP就相當於可以設定254乘以254台電腦 ,有64516個IP位址。

    而IP的第三個X也可以從0到255之間任一個數字變192.168.X.X。

    如果還要更多,那麼可以設定成255.0.0.0,區域網路就可以擁有254*254*254台電腦。

    不過這樣設定的話相當於這些所有電腦都處於一個區域網路裡面,而且可以互相訪問,容易引起“網路風暴”,所以我們在修改子網路遮罩時,應該盡量精確。

    例如:255.255.252.0,可以容納,4*254個ip位址。

    二、增加路由器

    也可以透過路由器後面再接路由器來分成多個網段,不過這種方法不太適合超大型網路。

     

    如果原來的網段為192.168.1.1。 那麼可以新增網段,192.168.X.1 。

    操作步驟:

    新增加一台路由器即可! 分配一個IP位址給新增的路由器靜態IP綁定下,然後如果想省事可以啟用DHCP,如果不想省事就自己設定IP位址。

    路由器的網關一定要改! 一般預設的都是192.168.0.1 或 192.168.1.1 ,你新增網段的網關應該是192.168.X.1切記!

    如果你新設定IP位址設定為192.168.2.1的話。 新路由器的IP位址池可以在 192.168.2.2~~~192.168.2.254之間。

    連接方法:

    之前的路由器LAN口和現在路由器的WAN埠相連接。 然後你新的路由器就可以上網了。 可以再接一個交換器插在新路由器的LAN口。

    三、劃分vlan

    最好的方法是透過設定虛擬區域網路“VLAN”,將區域網路裡面的電腦分成多個虛擬的區域網,可以減少網路風暴,而且可以提高交換器跟路由器的工作效率。 有的交換器自帶有VLAN接口,那麼只要將網路線依需要分別接到對應的網段。

     

    透過子網劃分! 你可以將IP位址設定成192.168.0.0/24
    那麼可以劃分192.168.0.x和192.168.1.x二個網段,增加了IP的數量,當然也可以續繼續劃分多個網段。

    網段一:

    192.168.0.x,192.168.0.1——192.168.0.254 ,255.255.255.0。

    網段二:

    192.168.1.x ,192.1681.1——192.168.1.254,255.255.255.0。

    這樣就劃分了兩個vlan,當然也可以分更多。

    四、補充

    這裡面弱電君補充下,很多朋友在專案中會遇到,ip位址192.168.0.0/23這樣的表示,是如何算出它的子碼掩碼是255.255.254.0?

    23是CIDR值。 簡單說就是一個CIDR值對應一個子網路掩碼,然後對網路就行分段。

    每個IP位址的長度為32位元(bit),分4段,每段8位元(1個位元組)。 簡單的說23代表從前往後有23個1,就是11111111.11111111.11111110.00000000

    把這個轉換成十進制就是255.255.254.0,子網路遮罩就是這樣算出來的。

  • 雲端運算的標準定義

    雲端運算這個概念與概念起源很早,早至二十世紀八十年代就有SUN 公司提出「 網路是電腦」 的思想,用來描述分散式運算技術帶來的新世界,今天的雲端運算正在 將這理念變成現實。

    雲端運算、雲端服務、雲端平台等概念名詞非嚴格來講都是指的同一件事。 百度百科是這樣解釋雲端運算的:雲端運算 ( Cloud Computing )是基於互聯網的相關服務的增加、使用和互動模式,通常涉及透過互聯網來提供動態易擴展且經常是虛擬化的資源。 雲端運算的定義有多種說法,對於到底什麼是雲端運算,至少可以找到十幾種解釋。 現階段廣為接受的是美國國家標準與技術研究院( NIST )定義:雲端運算是一種按使用量付費的模式,這種模式提供可用的、便捷的、按需的網路訪問, 進入可配置 的計算資源共享池(資源包括網絡,伺服器,存儲,應用軟體,服務),這些資源能夠被快速提供,只需投入很少的管理工作,或與服務供應商進行很少的交互。 可以從定義中提取一些關鍵字:按量付費、資源池、快速提供、少管理工作等。 關於雲端運算可以提煉出一個 “5+3+4” 模型,即:

    5 個基本特徵:按需自助服務、廣泛的網路存取、資源池、快速彈性、測量服務;

    3 種服務模式:雲端軟體即服務( SaaS )、雲端平台即服務( PaaS )、雲端基礎設施即服務( IaaS );

    4 種部署模式:私有雲、社群雲、公有雲、混合雲。

    對於雲端運算的理解,從簡單類比來說,常用的比喻有水力發電、水果等日常場景,但從技術角度來看,雲端運算實質就是將資源池化:包括運算資源、儲存資源、網路資源 和安全資源甚至包括管理資源和人力資源等。 這些池化的資源可能是部署在自己的機房供其他人使用(此時你是雲端服務供應商),也可能是你不再需要購買硬體設備和建立機房,直接租用別人的資源(此時你 是雲端服務客戶)。 這樣做有什麼好處呢? 對於雲端服務供應商而言,將池化的資源進行使用並且加以利用對外界提供服務,既提高資源利用率又能夠獲得額外的收益;對於雲端服務使用客戶而言,不再需要建立機房和購買 實體設備,直接使用池化資源,更快速方便。

    雲端運算的主要特點有如下:按需服務、快速部署、彈性伸縮、自助計費、持續可用、超大規模運算能力、成本低(成本是否真的降低有待進一步探討)。