Cisco、Canonical 宣佈支持開放源碼雲端平台 OpenStack

由 NASA 和管理服務供應商 Rackspace Hosting 共同開發的開放源碼雲端架構平台 OpenStack，日前獲得來自 Cisco Systems、Canonical 在內等新成員的支持。OpenStack 更宣佈代碼 Bexar 的第二次公開釋出版本，其中包含了對其計算 (Compute) 與物件儲存 (Object Storage) 平台的更新，並首度納入新的虛擬機器映像登錄與遞送服務 Glance。

OpenStack 是一套免費的開放源碼平台，可供服務供應商用以提供基礎架構，類似於 Amazon Web Services 的 EC2 和 S3。該平台主要分為 2 個部份，Nova 是最初由 NASA 所開發的電腦處理服務，Swift 則是 Rackspace 開發的儲存服務元件。

新釋出的 Compute 元件部份增加了對 IPv6、微軟 Hyper-V、iSCSI、Citrix XenAPI、XenServer 快照的支援，並且納入了代號 Glance 的映像找尋和遞送子專案，可達成工作負載在 OpenStack 雲端間的可移性。Bexar 釋出將 Object Storage 的物件由 5GB 擴充至不限大小。

OpenStack 專案此次公佈了 4 個新成員，其中包括 Cisco、Ubuntu Linux 商業贊助者 Canonical、Extreme Networks、Grid Dynamics。隨著新成員的加入，OpenStack 聯盟已達 50 個成員，其中包含了 AMD、Citrix、Dell、Intel。

同時也是 VMware 緊密合作夥伴的 Cisco，其雲端運算部門技術長 Lew Tucker 表示，Cisco 樂於宣佈該公司加入 OpenStack 社群的貢獻成員之列。他認為，網路供應與網路為基礎的服務是雲端運算中的基礎元件，他們期盼與社群一同確保此一開放源碼專案的成功。Rackspace 業務開發副總裁 Mark Collier 指出，Cisco 預期會為該專案貢獻程式碼，以便讓用戶更容易在 OpenStack 環境中設定 Cisco 的交換器。

儘管並非 OpenStack 會員之一，微軟表示其 Hyper-V 虛擬化軟體將可運用於 OpenStack。事實上這次釋出的 Bexar 版本中，就包含了對微軟 Hyper-V hypervisor 的支援，此一貢獻是由 Cloud.com 在微軟協助下所完成。OpenStack 過去已可支援紅帽的 KVM 和 Citrix Systems 的 XenServer。

Collier 表示，OpenStack的設計原本就與 hypervisor 相互獨立。他透露，列表上缺少的 VMware 的 ESX Server，將於今年稍後加入支援。OpenStack 貢獻者已經投入開發工作，其中包括了來自 Citrix Systems 的開發者。儘管 VMware 擁有自己的雲端建構軟體，vCloud，Collier 表示歡迎 VMware 隨時加入 OpenStack 聯盟。

OpenStack 的競爭對手包括 Amazon Web Services 的 EC2、相容於 Amazon Web Services 的開放源碼平台 Eucalyptus、VMware 私有的 vCloud、Nimbula Systems 的開放源碼 Director 雲端作業系統。不久前 Internap 成為 Rackspace 和 NASA 之外，第一家以 OpenStack 為基礎提供服務的公司。其 XIPCloud Storage 服務目前處於 beta 階段。

去年 10 月才推出第一個釋出版「Austin」的 OpenStack，其實還算是個初創的專案。因此 Rackspace 希望來自 Cisco 這類大公司的支持，可以讓企業對於該軟體更具信心。Collier 指出，有關雲端平台的決定影響重大，假如用戶想要採納一套雲端平台，特別是開放源碼平台，支持該平台的公司越可靠，對於該平台的存續用戶越能夠感到放心。

Canonical 主席 Mark Shuttleworth 表示，Canonical 會在預計 4 月推出的 Ubuntu 11.04 中，同時納入以 OpenStack 和 Eucalyptus 為基礎的雲端選項。Rackspace 技術長 Jim Curry 表示，Canonical 正在設法大幅簡化 OpenStack 的環境建置。過去 Canonical 一直是 Eucalyptus 的支持者，並以該平台作為 Ubuntu Enterprise Cloud 的基礎。Shuttleworth 指出，真正重要的是我們開始在雲端的基礎架構層次上，看到些許標準化的影子。Eucalyptus 和 OpenStack 都位於此一過程中的中心。

和 NASA 合作運行其雲端環境的 Anso Labs 共同創辦人 Jesse Andrews 表示，OpenStack 代號 Cactus 的下一釋出版本開發工作已經在進行中，其主要目標之一是為電信與服務供應商的大規模部署，提供足夠的穩定性，


相關網址：
1.Cisco 支持 OpenStack 雲端平台
http://news.yahoo.com/s/pcworld/20110203/tc_pcworld/ciscobacksopenstackcloudplatform
2.Canonical 與 Cisco 歡迎 OpenStack 的 Bexar 釋出
http://www.eweekeurope.co.uk/news/canonical-and-cisco-welcome-openstacks-bexar-releases-20057
3.OpenStack 釋出 Bexar 更新
http://www.v3.co.uk/v3/news/2274593/openstack-bexar-cloud-computing
4.OpenStack 的 Bexar 雲端作業系統增添 VM 映像登錄服務
http://www.sdtimes.com/link/35243
5.OpenStack 'Bexar' 釋出加入跨 Hypervisor 支援
http://www.informationweek.com/news/cloud-computing/infrastructure/showArticle.jhtml?articleID=229200430&subSection=News
6.Canonical 將 Ubuntu 帶向 OpenStack 雲端
http://www.zdnet.com/blog/open-source/canonical-brings-ubuntu-to-the-openstack-cloud/8204
7.OpenStack：只會有一種 Ubuntu 雲端平台
http://www.theregister.co.uk/2011/02/03/openstack_on_ubuntu_partnership/
8.Canonical 加入 OpenStack 社群
http://www.theinquirer.net/inquirer/news/2024215/canonical-joins-openstack-community
9.OpenStack 雲端平台新增 Bexar 釋出和支持者
http://www.zdnet.co.uk/news/cloud/2011/02/04/openstack-cloud-gets-bexar-release-and-backers-40091682/
10.OpenStack 雲端作業系統專案宣佈 Bexar 釋出和新夥伴
http://ostatic.com/blog/canonical-spreads-its-open-cloud-wings-with-openstack

CDN (Content delivery network)

CDN (Content delivery network) 被稱為「內容傳遞網路」是一種內容快取機制，能提供高效能 (包括使用者以及內容提供者)、高可靠度、低成本的內容傳遞架構。不過，這幾個優點並不一定同時會發生。以對使用者高效能這點，通常指的是「就近取得檔案」，內容提供者事先將檔案推到全球的 CDN 節點，在台灣的下載者儘量從台灣取得檔案，在日本或香港的下載者也儘量從當地的伺服器取得檔案。由於在全球有多個節點，所以當某個節點不通時，可以導到次近的節點以達到高可靠度。對 內容提供者高效能的部份，是因為內容提供者不需要在一個 data center 上建立非常粗的水管。舉例來說，如果傳遞需要 100Gbps 的流量，利用 CDN 架構，每個 data center 也許只需要 5Gbps 的流量。由於十個 10Gbps 網路與 100Gbps 網路的成熟度不同，成本也會不相同。

這是 CDN 的一些粗略的概念。

用 CDN 最常見的兩個理由：

* 速度：下載者可以就近取得檔案。這對於小檔案 (css/javascript) 會有很大的幫助。(也許要解釋瀏覽器 HTTP 的運作，並抓一張 Firebug 的畫面分析？)
* 效率：因為下載者透過 CDN 下載，可以減少原始 server 的負荷。

另外還有其他的理由：

* 成本 

* 安全：以分散架構對抗 DDoS 攻擊。

要決定使用者應該要到哪組 server 通常有這些方法：

* GeoDNS
* Anycast
* HTTP Redirect (會比較差)

這幾種不衝突，常見的是前兩者搭配著用。將 DNS server IP anycast，當下載者要抓某個 domain 時，近的 server 就會知道大致的區域。再配合 GeoDNS 判斷使用者的 IP address 適合到哪個 node。

不過這些問題對 HiNet 就很麻煩。(留到現場講)

再來就是 reverse proxy cache 所產生的問題，這個部份再想看看要怎麼寫。

前三大 CDN 服務提供者：

* Akamai
* Limelight Networks
* CDNetworks

其中 PIXNET 用的 Panther Express 前陣子被 CDNetworks 收購。

另外，很熱門的：

* Amazon CloudFront

Amazon CloudFront 有公開的價錢，Akamai 與 Limelight 也有可以參考的價錢：(只是參考用)

* Distributed Cloud (Akamai)
* Mosso Cloud Files (Limelight Networks)

其中 Akamai 國內有代理商 (併力科技)。

另外還有一些可以參考 Wikipedia 上的表。

要挑什麼 CDN 是依照需求而決定，我會談的是台灣的情況。

在台灣有「用戶」的 ISP 中，HiNet 與 TANet 的出國線路狀態是最差的，其他 ISP 的情況會好很多，所以測試的重點要放在這兩個 ISP。

以 影音來說，由於傳輸時間普遍會大於一秒，重點在於 bandwidth 而非 latency。所以到台灣抓與香港、日本，甚至到美國抓其實都 okay，只要 thoughtput 夠高就可以。以 1M 高畫質的影片換算，有穩定 150KB/sec 的速度其實就很順，如果是 600K 或是更低，有穩定的 100KB/sec 以上就 okay。

如果是 css/javascript，因為檔案很小，latency 就變得很重要。可以從台灣本地提供檔案通常是最好的 (<10ms)，或是從日本、香港 (~20ms 到 30ms) 提供，如果 CDN 業者可以幫忙 gzip 會更好 (因為他們會處理 IE6 的一卡車問題)。

如果檔案是屬於下載性質，速度其實不是重點，重點在於成本的話，有些 CDN 業者有提供「經濟型網路」，通常是用北美較便宜的點提供下載。有一定的 commit 時會比 Amazon S3 的 USD$0.17/GB 便宜。

轉貼http://freemannote.blogspot.com/2009/03/content-delivery-network-cdn.html

Share nothing架構 分散式運算

Shared nothing架構（shared nothing architecture）是一 種分佈式計算架構。這種架構中的每一個節點（ node）都是獨立、自給的，而且整個系統中沒有單點競爭。有些系統需要集中保存大量的狀態信息——數據庫、應用服務器或是其他類似的單點競爭系統。
   Shared Nothing在Web 應用開發中尤其受到歡迎，究其原因是這種方案提供的scalability。Google在這個方面做了很好的示範。 在一個純Shared Nothing系統中，通過簡單地增加一些廉價的計算機做為系統的節點卻可以獲取幾乎無限的擴展。正是由於Shared Nothing架構中不存在單一瓶頸而降低系統運行速度。Google 稱之為sharding。 Shared nothing系統通常需要將他的數據分佈在多個節點的不同數據庫中（不同的計算機處理不同的用戶和查詢）或者要求每個節點通過使用某些協調協議來保留它自己的應用程序數據備份 ，這通常被成為數據庫Sharding。
   現在對一個有著多個獨立的web節點卻存在一個惟一的共享數據庫這樣的架構是否能被稱之為 Shared nothing架構還是有很多爭論的。一個狀態型的應用（通常將狀態保存到一個集中化的數據庫中）要獲得shared nothing架構就需要通過數據網格和分佈式Cache。 但即便是這種架構，數據庫依然是故障單點。

OpenStack Nova 概念 與系統需求

OpenStackCompute，一種雲計算軟體，控制您的基礎設施（IaaS）雲計算平台。 它類似於Rackspace與 Amazon EC2雲服務器。 Nova 不包括任何虛擬化軟體，您的主機上運行的作業系統所defines drivers與底層交互溝通的一種虛擬化機制，且 Nova公開API能通過 Web。


Nova is written with the following design guidelines in mind:

• 組成的基礎架構:快速擴充運算
• 高可用性: 支援可延展到非常重的計算工作量
• 容錯:隔離錯誤計算,避免連鎖錯誤
• 可恢復度: 故障應該很容易診斷，調試和糾正
• 開放標準: 做一個可參考實現一個共同驅動的API
• API Compatibility:致力於提供API的兼容與廣為流傳使用的系統，像Amazon的EC2Amazon EC2

關鍵概念

 

AMQP (Advanced Message Queuing Protocol) 協定

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security^[1].AMQP mandates the behaviour of the messaging provider and client to the extent that implementations from different vendors are truly interoperable, in the same way as SMTP, HTTP, FTP, etc. have created interoperable systems. Previous attempts to standardise middleware have happened at the API level (e.g. JMS) and this did not create interoperability^[2]. Unlike JMS, which merely defines an API, AMQP is a wire-level protocol. A wire-level protocol is a description of the format of the data that is sent across the network as a stream of octets. Consequently any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of implementation language.

System Requirements

Hardware: OpenStack components are intended to run on standard hardware.
Operating System: OpenStack currently runs on Ubuntu and the large scale deployments running OpenStack run on Ubuntu 10.04 LTS, so deployment-level considerations tend to be Ubuntu-centric. Community members are testing installations of OpenStack Compute for CentOS and RHEL and documenting their efforts on the OpenStack wiki at wiki.openstack.org. Be aware that CentOS 6 is the most viable option (not 5.5) due to nested dependencies.
Networking: 1000 Mbps are suggested. For OpenStack Compute, networking is configured on multi-node installations between the physical machines on a single subnet. For networking between virtual machine instances, three network options are available: flat, DHCP, and VLAN.
Database: For OpenStack Compute, you need access to either a PostgreSQL or MySQL database, or you can install it as part of the OpenStack Compute installation process.
Permissions: You can install OpenStack Compute either as root or as a user with sudo permissions if you configure the sudoers file to enable all the permissions.

MailArchiva OES安裝

1.環境 CentOS 5 8gb Ram 1.5TB HDDA.MailArchiva OSE  安裝步驟
OS :CentOS5.5  + Sendmail
1.下載 http://sourceforge.net/projects/openmailarchiva/files/mailarchiva/( 須選擇Linux 版本)
2.tar zxf mailarchiva_server_opensource_linux_*.tar.gz
cd mailarchiva_dist
./install.sh
chkconfig mailarchiva on
3. 安裝過程 按 Enter 忽略所有 "registration details"
4.設定設定 Sendmail
cd /etc/mail
vi sendmail.mc
INPUT_MAIL_FILTER(`mailarchiva',`S=inet:8092@MailArchiva主機IP')    
m4 sendmail.mc > sendmail.cf

(選項)預設自動辨識使用者端語系 (中文為簡體), 若要強迫使用英文介面可調整如下:
cd /usr/local/mailarchiva/server/webapps/mailarchiva/WEB-INF/classes/properties
mv application_zh.properties application_zh.properties.backup
ln -s application.properties application_zh.properties
/etc/init.d/mailarchiva restart
6 .設定 MailArchiva

7.瀏覽器連入 http://IP:8090/mailarchiva

• User Name: admin
• Password: admin (預設)

OSE 版 沒有的功能
Email Archiving
Attachment de-duplication