對思科的期望：在路由器中實現虛擬伺服器

今天的思科正在努力兌現其計畫啟用IOS(網際作業系統)的承諾，而且至少到現在為止，相應的開發成果已經運行在其ISR(集成多業務路由器)中。 上述路由器能夠運行那些使用思科提供的SDK創建的協力廠商應用程式，這也是思科試圖借用虛擬化技術取代網路基礎設施伺服器的第一步。 雖然IOS還沒有像Windows系統那樣開放(思科已經在支援Linux系統，且該系統本身就是開放的)，但它仍然能允許使用者將協力廠商應用程式植入ISR，這樣就削弱了使用者資料中心的回流資料量， 從而減少了分支機搆路由器的工作負載及壓力。 雖然思科在進軍伺服器領域的戰略上曾是呼聲最大的廠商，但是它並不是唯一一家在路由器中裝載可以運行協力廠商應用的平臺的廠商。 人們更應該把對投身這一技術的讚譽給予3com公司，因為它早在1年前就已宣佈其OSN(開放服務網路)可以作為應用程式的植入平臺，並且當時Riverbed也已經推出了WAN(廣域網路)優化的簡易版產品。 從宏觀部署來看，思科的產品與3com的產品非常類似：兩者都涉及到了分支機搆的路由器，但是兩者都沒有直接在路由器上放置協力廠商應用。 相反，思科和3com都將協力廠商應用運行在一個獨立的新加模組上，該模組實際上就是一個遞減的刀片伺服器。 如果相比僅用軟體途徑植入協力廠商應用的Riverbed，思科和3com採用單獨再加一個模組的方式的確增加了使用者成本，但是對於x86平臺，當這些應用程式正在和路由器爭搶運行中必需的處理器、記憶體以及硬碟資源時， 採用單獨的模組則更有助於從路由設施中分離應用程式對資源的爭搶。 而當3com一直採用單一的OSN模組時，思科卻因為有不同的ISR模型而擁有不同擴展刀片的兩個獨立產品，並且有適用于中高端1841、2800以及3800的ISR，同時適用記憶體的容量範圍為256MB~2GB。 思科的這些型號並沒有參照很多伺服器的標準(或其他任何標準)，但卻類似于3com的1GB模組。 當然，思科和3com的研發目標都是非常希望由分支機搆少量工作人員使用的服務能運用到這些模組上，而不是使整個資料中心都虛擬化。 思科的模組運行在所謂的AXP(應用擴展平臺)上，並且其IOS的一個新版本是基於Linux平臺的。 這種設計理念使模組中植入應用程式相對容易一些，但是思科特有層的存在意味著該作業系統並非對任何Linux分發方案都是一致的。 至少，Linux應用程式需要再次編譯，而對於那些有效訪問路由器的特性，使用者還需要重新使用API編寫訪問程式。 但是無論如何，路由器不會只承載某些應用程式，它的安全架構需要有標識的代碼，而且思科一直對自己標識的那些私有密碼戒備森嚴。 放置在路由器上的每一個應用程式，即使是那些使用者開發來完成內部應用的程式，也必須在運行之前得到思科的允許。 對此，思科方面的解釋為，一個應用程式顯然只有在得到許可後，使用者才可以無償得到標識的密碼，但是需要完全由思科許可的想法，本身就會很自然地導致一些使用者對路由器開放性的質疑。 API僅僅是應用程式能夠直接在模組上運行的實現途徑，意思是模組記憶體的系統規定參數空間嚴格限制了其上能運行什麼樣的應用程式。 然而，使用者或協力廠商開發者們可以通過在模組上編寫代理來客服這些限制條件，這個代理可以將資料輸送到其他地方的JAVA或Windows伺服器上。 就像3com一樣，思科也已經簽署了好幾個合作夥伴來共同開發路由器應用程式，但是這兩個企業卻有著不同的合作戰略：思科已經在很多領域擁有了自己的產品，如安全、VoIP以及3com也正在攻克的應用。 最初，思科有九家合作夥伴，包括Avocent，該廠商旗下的LANDESK管理軟體將能被運行在路由器上。 其他合作夥伴則都是整合通訊領域或指向特定產業領域的。 舉例來說，當NICE系統公司需要面向金融服務和政府部門記錄電話時，Sagem-Interstar公司正好有一個應用是截獲VoIP線路中的傳真呼叫的，思科的分銷商ICW系統公司就將醫療記錄保持應用與ISR綁定， 並稱該植入應用後的設備為保健型路由器。 顯然，諸如思科和3com所重視的協力廠商應用植入路由器的思路，很大程度上為使用者減少了各種應用伺服器在硬體上的開銷，同時又能減少應用中產生的下行流量。 只是隨著時光的變遷，加之各種網路優化廠商，如Riverbed等廠商的努力，思科在路由器上的突出優勢能否繼續延伸到植入應用後的市場認可中?思科的網際開放戰略是否真正能給使用者帶來應用的開放? 使用者選擇怎樣的優化策略能更有效達到高的收入支出比?使用者似乎還需要拭目以待!