雲端記事本Evernote 讓你多了一個腦袋！

作者：邱淑美 / 臺灣大學計算機及資訊網路中心程式設計組程式設計師

---

常煩惱事情記不住、臨時找不到紙筆、或忘了帶文件或小抄嗎？趕快來學習使用免費的雲端服務Evernote，讓你走到哪都沒有這些煩惱，好像自己多了一顆永不會遺忘、沒有記憶限制的腦袋了！

前言
雲端充滿太多美好的服務了，讓人可以無論走到哪都能享受到它的便利。不但讓你的休閒生活更多采多姿，而運用適當的工具，更能提昇你的創造力，讓你獲得更大的成就！
下面就來介紹這項讓你在資訊爆炸的時代，可以更得心應手、無記憶負擔，而且又免費的文件整理工具 - Evernote ！

Evernote雲端服務簡介Evernote 是由美國Stepan Pachikov 所創建的網路服務，於2008年6月24日正式上線，總部設於美國加州紅木城 Redwood City，是一個功能非常單純的數位筆記應用工具，可以結合文字輸入、照相、錄音等方式，把自己想要的資料被保存起來，而其最大的優點在於它的雲端管理機制，因為它可以支援的多種平台，所以允許用戶在不同地方、用不同設備上去存取自己的筆記，即使沒有網路時，用戶也一樣可以在本機查看、編輯筆記。等到有網路時，無論是你在電腦上的資料、或是使用手機拍下來或錄音的檔案，都會自動同步至 Evernote 的雲端伺服器上，所以用戶彷彿多了一個腦袋在雲端，不用怕會忘記任何重要的事物，也讓你更容易整理與搜尋收集來的資料，減少紙本筆記反覆抄錄或剪貼的麻煩。

Evernote所支援的平台Evernote 可以支持使用的平台有Microsoft Windows、Mac OS X、Chrome OS、Android、iOS、WebOS、WebOS、Maemo、BlackBerry OS、BlackBerry Tablet OS、Google Wave以及 Symbian OS的第5版，甚至離線時的隨身碟，所以幾乎所有各家廠牌的桌機及筆記型電腦、平板電腦、手機等行動裝置都一網打盡，保證用戶隨時隨地都能取用你的雲端記事本，而且沒有版本控制的問題！更棒的是學習門檻並不高，很簡單就能開始使用！

Evernote讓你輕易就上手

一、 先上網註冊帳號使用任何瀏覽器先到Evernote官方網站 http://evernote.com/
註冊自己的帳號（可依下圖指示選擇只是建立新帳號或一併安裝Evernote client）

　

二、 手機上安裝Evernote App以iPhone 5為範例，左圖以Evernote 搜尋App；右圖是安裝好App之後呈現的畫面。

　

三、 建立記事第一次登入時會出現Evernote 所內建的「開始使用」記事，用來給用戶介紹怎麼開始使用（如下圖）

要新增自己的記事時，可按「新記事」（如下圖）

或

　

四、 編輯記事每一則記事都可以自行訂定清楚的標題，方便日後開啟記事來查資料或繼續編輯，標題輸入框在下圖右上方，而點一下右下方的編輯視窗便可以開始進行輸入或編輯，記事的格式是採網頁HTML格式，所以可以直接複製其他網頁或文字進來，也可以直接進行版面的編排。

　

如果是使用一般瀏覽器進行編輯，在點選記事後，需要先按 才能開始進行編輯，而且結束後要記得按「完成」，以避免同時於不同client進行修改，而發生「修改發生衝突」的問題。

　

五、 拍下眼前所見若是使用有相機功能的行動裝置開啟Evernote記事時，也可以直接使用相機功能拍下來記載在記事裡。下圖以iPhone 5為範例來說明操作方式：
1. 按上方「相機」圖示，以便取得圖片。
2. 可選擇進行「拍照」，或「選擇現有」直接從相簿取得圖片。
3. 按「相機」圖示、進行拍照
4. 按 結束拍照。
5. 回到記事，相片已經貼進該記事了。

　

六、 錄下目前所聽若是使用有錄音功能的行動裝置開啟Evernote記事時，也可以直接使用錄音功能現場收音，把聲音檔記載在記事裡。下圖以iPhone 5為範例來說明操作方式：
1. 按上方「麥克風」圖示，開始進行錄音。
2. 按「完成」圖示結束錄音
3. 回到記事，錄音檔已經貼進該記事了。

　

七、 同步記事當你開啟Evernote時，如果是在有網路的環境，會自動開始進行同步、從伺服器取得最新的版本，若有修改也會立即儲存至雲端。
而沒有網路的情況下開啟Evernote時，則會取得目前在該裝置上的版本，若有進行任何修改時，記得在有網路的情況下，要先開啟最近離線修改過的版本，以便將離線時的修改同步至雲端。
下圖是iPhone 5「修改發生衝突」的一個範例，所以要注意在不同地方編輯時，確定上一版本有先被同步過了，然後再開啟另一裝置上的記事。
若萬一發生下列衝突，也可以在該記事進行編輯，將重複的部分刪除，整併成正確的版本。

　

Evernote讓你輕易就分享當你陸陸續陸蒐集好資訊，並完成了一篇完整的報告或文章後，還可以將該記事產生連結、寄給同事或朋友喔。方法也是很簡單：
1. 在開啟的一篇記事，按右上角「傳送」並選擇「連結」
2. 複製記事URL，便可以寄給朋友了。

　

結語使用簡便的Evernote讓你的靈感、所見所聞可以馬上被記錄下來，不管身處何地，都能馬上取得記事，而資料的蒐集與整理也變得格外的輕鬆了，不再擔心忘記或遺漏待處理事項，更可以進一步進行分享或共筆。行動化的雲端服務，讓大家的日子真的越來越輕鬆了。
　

參考資料1. Evernote維基百科
　http://zh.wikipedia.org/wiki/Evernote
2. Evernote：所見、所聞、靈感思緒直達雲端儲存管理的必備工具！
　http://3cpjs.com/blog/evernote-is-a-note-what-you-see-and-thinking-can-be-strorage-to-cloud/
3. 善用Evernote數位筆記術的10個必備觀念
　http://playpcesor.blogspot.com/2012/04/evernote-10.html

資料來源

雲端建置-選擇機架式伺服器或是刀鋒伺服器

作者：陳柏鍠 / 計算機及資訊網路中心作業管理組幹事

---

以自行建置的方式提供組織專屬的雲端服務，伺服器數目的增加就是一個不得不因應的課題。如何增加服務容量，又要做到節能減碳呢？在此希望透過一些經驗分享，讓IT決策者與系統管理者了解機架式伺服器(Rack)還有刀鋒伺服器(Blade Server)的差別，希望能幫助大家選擇最適合的建置方案。

 以下我們就空間、擴充性以及管理便利性等面向，向各位讀者介紹機架式伺服器(Rack)與刀鋒伺服器(Blade Server)的差別：

圖1、IBM X3550 M4機架式伺服器

　

圖2、IBM HS20 Server刀鋒伺服器

　

圖3、IBM Bladecenter機箱

　

空間與布線機架式伺服器(Rack Mount)伺服器與刀鋒(Blade)伺服器外觀上的最大的差別是體積。刀鋒伺服器是數刀共用一個機箱，機箱內有光碟機模組，網路模組、電源模組、風扇模組，因為這些模組都是共用，所以可以省下不少空間。以IBM Blade Center舉例來說，高度為9U，但是共可以塞進去14台刀鋒伺服器。相對而言，如果是機架式建置的話，14台1U伺服器當然就要占14U的空間。

機架式伺服器，若每台有兩張HBA光纖介面卡，六張乙太網路卡，兩個電源供應器模組，就有十條線路在後面；若有十台以上，後面就有上百條的線需要整理，還需要更多的插座。這對於系統管理者是一個挑戰，畢竟各種線路沒有整理好會造成日後管理不便，影響散熱，還很容易踢到。這部分就是刀鋒伺服器的強項了，因為是共用電源供應器跟網路，所以電源線跟網路線都可以大幅減少，機器後面看起來就比較清爽。

擴充性只要比到這點，刀鋒伺服器就稍微失去優勢，因為本身體積比較小，因此在擴充性上比機架式小。我們各以IBM X3550 M4機架式伺服器還有IBM HS23刀鋒伺服器來比較：

	IBM X3550 M4(機架式)	IBM Blade Server HS23(刀鋒式)
CPU	最大兩顆	最大兩顆
記憶體	24個插槽	16個插槽
硬碟	8* 2.5吋	2*2.5吋
擴充槽	2 * PCIe 3.0 插槽	可擴充兩張刀鋒伺服器專用卡 (網路須與機箱之模組整合)
RAID支援	RAID 0,1,5,6,10	RAID 0,1

　

這邊可以看到記憶體插槽差了8個，以現在記憶體的價格來說，當然是多多益善。假如您的機器是要當虛擬化的實體機器，少插了這麼多條，對於不便宜的虛擬化授權來說，當然比較不划算；另外，硬碟方面也是一個致命傷，刀鋒伺服器如果需要更多的儲存空間，只能仰賴外接的Storage。

網路方面就比較特殊，機架式伺服器就是插了幾張卡就是幾張，比如你總共有兩張 4 Port的乙太網路卡，作業系統裡面就看得到八張乙太網路卡。但是刀鋒就不太一樣，一開始購買的時候就要確認自己買的網路卡是什麼等級，比如每台刀鋒伺服器預設是2 Port乙太網卡，後來加購買了一張2 Port乙太網卡，這些網卡不是你已經可以用的，還要配上機箱後面的網路交換器模組才可以用。一張乙太網卡會對到一個網路交換器模組，如果你每刀共計有4 Port乙太網卡，但是機箱後面只有兩個乙太網路模組，這樣你還是只能用兩張。也因此購買的時候就要考慮到未來會買幾台刀鋒伺服器，要拿來做什麼用途，網路模組要怎麼配置比較好(14刀裡面只有一刀需要用到6 PORT網卡，其他只需要2 Port，卻因此買六個網路交換器模組是不經濟的。

以上的網路設定只是舉一個例子，現在刀鋒伺服器的網路模組每家廠牌都有獨到的設計，像有的廠牌的刀鋒伺服器網路模組就是虛擬化的方式，每張網卡都是網路模組虛擬出來給刀鋒伺服器用的，這樣的方式也比較有彈性。

管理傳統的機架式伺服器管理就比較簡單，通常會有一個WEB化的管理介面。裡面就是一些顯示系統資訊、Log及查看各個裝置的平台，即使沒什麼學過，初學者也可以蠻快上手。但刀鋒伺服器就比較不一樣，由於管理介面裡頭可以看到這台刀鋒伺服器的系統資訊，可以透過介面看到前面伺服器的遠端畫面，也可以透過介面控制開機或關機，也因為機箱都有整合乙太網路及光纖介面卡模組，設定上會比較繁瑣，主機管理人員同時也要有網路相關知識才比較好上手，需要有相當時間的熟悉才可以操作。

散熱
刀鋒伺服器由於體積小、元件密集，導致散熱的要求比機架式還高，如果機房散熱不佳，使用刀鋒伺服器會更容易過熱當機。機架式伺服器由於內部空間比較大，散熱就比較好。
　

結語因為各項資訊系統的需求不同，如果你需要建立的是有大量虛擬機器的環境，那記憶體的數量及網路應該是優先考慮的，這部分會建議用機架式伺服器比較好，因為相較於刀鋒伺服器，可以插更多的記憶體及擴充較多的網路卡。如果你的機房空間不足，也沒有太多虛擬化的需求，這時候用刀鋒伺服器就會比較適合，可以節省不少空間。
　

參考資料"刀鋒伺服器- ?基百科，自由的百科全? - ?基百科- Wikipedia." 4 Jun. 2013,
http://zh.wikipedia.org/wiki/%E5%88%80%E9%8B%92%E4%BC%BA%E6%9C%8D%E5%99%A8

資料來源

幫你的雲端服務打造一個穩固的地基

作者：陳柏鍠 / 計算機及資訊網路中心作業管理組幹事

---

大量的資料及服務不斷湧向雲端的同時，也不斷的在考驗雲端的穩定度。本文主要敘述在建置資訊系統時，從伺服器、網路、Storage及虛擬化的角度去思考並規劃具備高可用性(HA)的架構，增加系統的穩定度及彈性。

身在雲端時代，大幅更改了過去的經驗，眾多主機可以虛擬化到一台機器，還可以處理大量的檔案上傳，各種服務的佈署也更加快速，其實這些都考驗著雲端服務提供者的「系統穩定度」。由於跑在「雲」上頭的服務日趨重要，所以在建置的時候，也要考量到如何在各個關節去加強並預防災難的發生。本文便是以基礎環境建設的角度下，去討論各項雲端服務之高可用性如何達成，期能打造一個飛得很穩當的雲。

高可用性(High Availability)的目的為減少因為各種因素造成服務中斷的現象。在大部的情形下，也就是希望能在單點故障(Single Point Of Failure)時，整個系統還可以運作下去。以資訊服務的基礎建設來說，要達成HA的目標，大致可從以下範圍著手：

• 伺服器
• Storage
• 網路
• 虛擬化及容錯移轉叢集

伺服器以目前主流的Server來說，大部份還是購買機架式的1U及2U為主(1U為4.445公分高)，其實這兩者只差在擴充性，比較表格如下：

項次	1 U Server	2U Server
CPU	最大兩顆	最大兩顆
硬碟	8 * 2.5吋	16 * 2.5吋
記憶體	24個插槽	24個插槽
擴充插槽	2 * PCIe	6* PCIe
Power	支援雙Power	支援雙Power

表一、伺服器比較

其實要買哪一種，依照單位的需求來採買就好。一般來說，考慮到避免單點故障，因此建議電源供應器一定要裝兩個。如果貴單位的電力系統有兩條迴路，也建議可以分接在兩個電源供應器上，避免單條迴路損壞導致伺服器停擺。另外，在乙太網路卡方面，雖然預設已有2到4個連接埠，但實體還是從同一張卡出去，乙太網路卡的價位目前不算太高，建議最好另外擴充一張網路卡，並且將不同功能的線路分散在兩張網路卡上，這部分在網路部分會詳述。

StorageStorage為每個雲端服務的命脈，非常的重要，也建議一定要做到高可用性。一般要做到高可用性，最常見的做法就是買有雙控制器(Controller)的機型，並且要將線路分別接在兩個Controller上，設定MPIO(Multipath I/O)，才可在其中一個Controller發生單點故障時自動切換到第二個Controller繼續運作，也要確保Storage具有雙電源供應器的配置。如同前述，建議要將兩個Power接在不同的迴路上以確保電源供應無虞。

但如果有一天，資料不夠放，或是Storage老舊換新，需要停機時間搬資料，就會變得很麻煩。更難保哪天整櫃Storage都掛了，直接停擺給您看，這也不是沒有可能的。但是一旦發生了，Storage裡面存放的資料幾乎都是非常重要的，停機的時間和損失的金錢是無法估算的，這也說明了Storage作HA的重要性。有個解決方式，就是把一樣的資料存到兩個Storage去，這樣單台要停機維護，或是單點故障時都可以讓服務不中斷。聽起來是預算非常高的單位才有辦法作到，但考量到資料如果非常重要的話，還是可以針對重點去建置。目前市面上有軟體跟硬體的解決方案都可以作到 Storage的HA，甚至還有一些附加功能(Storage虛擬化、利用Cache加速、連續資料保護(CDP)、快照(Snapshot)等)，可以依照需求去挑選適合的解決方案。

在線路方面，不論您是用iSCSI或是Fiber Channel(FC)的介面，也是有一些可以努力做到高可用性的地方，本文會以FC來當例子，以下圖來解釋

圖一、 Storage高可用性架構
　

本架構是將前端(Server)跟後端(Storage)以SAN Switch切開。也就是上圖的Front End及Back End，中間用Storage Service Server作連結統整後方的Storage以提供前方的Server使用。具備兩台，中間會隨時同步確保資料正常。前端的每一台Server會各有一條光纖線連接至Front End 的SAN Switch，後端的Storage視頻寬而定要使用幾個光纖接頭至Back End的SAN Switch (比較新的Storage Controller至少會有兩個光纖接頭)。此架構的優點列舉如下：

• 線路連結整齊，伺服器端與Storage端分類清楚。
• 容錯程度高，可容許光纖線、SAN Switch、整櫃Storage損壞皆不會中斷儲存服務。
• 日後維護Storage設備不會有Downtime，也方便作資料轉移或Storage升級或擴充。

有人會有疑問，SAN Switch一次配置四台費用不會過高嗎? 其實SAN Switch比較特別，以本案使用的48 Port SAN Switch為例，雖然買來有48個連接埠，但初始只有16個可以使用，其他連接埠要使用需要購買License，與其花錢擴充還不如再買一台新的，在考量高可用性還有日後的擴充及管理，才會設計出此架構。

網路網路的部份為雲端服務最重點的基礎建設之一。因為流量的大幅增加，還有各式各樣的需求，都讓網路規劃變得非常的關鍵，以下會以臺大建置一個Hyper-V Cluster的例子來說明怎麼作到網路的高可用性：

建置說明：由於業務需要，計資中心需要新建容錯移轉叢集(Cluster)以提供虛擬機器服務，由於此機器上面運作的虛擬機器都非常重要，種類有AD服務，Exchange服務，Web服務等，不僅對外頻寬要足夠，還有即時移轉的需求(Live Migration)。

初期的準備項目如下：

Server	機架式1U主機四台
OS	Windows Server 2012 Datacenter
網路卡	每台預設有4 Port (1Gb)乙太網卡，額外擴充一張4 Port(1Gb)乙太網卡，合計共8 Port
網路配置	Access * 2 Live Migration + Heartbeat * 2 CSV Network * 2 Manage + Backup * 2

表二、建置Cluster前置規劃

• 註1：Access為提供虛擬機器對外連線用
  Live Migration：為虛擬機器在實體機器間移動所需連線
  Heartbeat：容錯移轉叢集主機間互相溝通之線路
  CSV Network：連結CSV(Cluster Shared Volumes)的專用線路
  Manage：管理專用的線路
  Backup：備份VM用線路
• 註2：每種網路皆有兩條，目的為Teaming起來可以增加頻寬，又有兩條實體線路可互為備援。

　

圖2、 網路高可用性架構

　

如圖所示，以上的網路配置，若有單張網路卡故障，單條線路損壞，單台Switch故障，單台防火牆故障，皆可以因為高可用性的關係，服務不中斷。由於網路線故障的機率比其他裝置高，所以請務必用專業廠商製造的CAT6網路線，可以的話要以顏色區分並加上套環，方便辨認。
　

圖3、 網路線比較

　

虛擬化及容錯移轉叢集：
伺服器虛擬化可以降低實體機器數量，並快速的佈署新機器及增減運算資源，現在主要的產品包括VMWare 及Hyper-V，兩者在最新的版本上皆進步許多，不論是實體機器或是虛擬機器的性能都提升許多，如下表所示：

		Hyper-V 3.0	vSphere 5.1
實體主機	邏輯處理器數量	320	256
	最大記憶體容量	4TB	2TB
	虛擬CPU最大數量	2048顆	2048顆
	可同時執行VM數	1024	512
虛擬機器	虛擬CPU最大數量	64顆	64顆
	記憶體最大容量	1TB	1TB
	虛擬磁碟大小	64TB	2TB
容錯移轉叢集 Cluster	同時執行主機數量	64台	32台
	同時執行VM數	4000台	4000台

表三、虛擬化產品比較

　

如果您已經決定要進行虛擬化，甚至要建置容錯移轉叢集，不管是何平台，皆要注意以下幾點：

(1) 各項硬體之韌體及驅動程式建置前需更新

由於建置叢集後，要做這件事會變得很麻煩，所以要趁建置前檢查一下，可以的話盡量更新最新的穩定版驅動程式或韌體。

(2) 網路架構要注意分流及HA

以虛擬機器移轉來說，要耗用大量的網路流量，單條1Gb線路可能不夠，這時建議要用兩條線路進行Teaming，互為備援並增加流量；另外備份的流量強烈建議要獨立開來，才可避免備份時的大量流量影響到虛擬機器。現在已經可以考慮採用10Gb線路，以應付日益俱增的備份需求，那如果貴單位的網路線路不夠多，卻想要使用容錯移轉叢集呢？也不是沒有辦法的，假使只有兩條1Gb的線路，也是可以做到HA的，就是用QoS方式來限制各種網路流量的上限[1]。如此叢集還是可以運作，只是網路高峰時速度稍微慢一點，並且此兩條線路也具備互相備援的功能。

(3) 連結Storage部份務必要設定MPIO

由於CPU及記憶體運作速度都很快，因此虛擬機器的效能大部分就決定在Storage。而叢集的命脈更是取決於共用磁碟區的健康，設定線路時請盡量以MPIO方式連接，並且要注意要各接在不同的Controller上。因為光纖線時間一久容易老化，您可不希望哪天只是因為線壞掉或更換線路，導致叢集上面的虛擬機器全部掛點吧!

(4) Hyper-V 容錯移轉叢集的AD要保持健康

建置Hyper-V 容錯移轉叢集一定要透過AD，在此架構下，所有實體機器間的互相溝通，還有與共用磁碟區間的連接，都仰賴AD，要是AD壞掉，您就會發現您的叢集也會廢掉一身武功，因此AD一定要兩台以上，以作為備援。如果您是因為要建新叢集所以要順便建新AD，也建議不要把AD的虛擬硬碟放在共用磁碟區上，最好放在實體主機的本機硬碟裡(所以AD虛擬機器不可以加入容錯移轉叢集的角色)，原因是如果有一天您無法連結到某一個共用磁碟區，剛好AD 的VM放在這個共用磁碟區裡，結果AD死掉，造成Cluster Crash，回復起來會很麻煩。

(5) VMWare的vCenter要考慮高可用性

vCenter是VMWare裡面最重要的角色之一，如果裝在實體機器上，萬一實體機器出現單點故障，就只能連進每一台ESXi Server進行管理，也無法作即時移轉(vMotion)，因此建議把vCenter裝在虛擬機器上，這樣單台實體機器故障時，才可以在叢集裡移轉，確保服務正常。
　

結語以上為筆者這幾年的經驗累積，也許還有不足的地方，但是實務經驗上，若在建置的每個細節都考慮到高可用性，實際運作時系統就會更穩定，在找尋問題的時候也會更快速，願大家的系統都永遠健康！

參考資料[1] "Windows Server 2012 Hyper-V Best Practices (TechNet Blogs." 4 Jun. 2013http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

資料來源

線上簽核-無紙化的最後一哩

作者：陳啟煌 / 臺灣大學計算機及資訊網路中心程式設計組副組長

---

清康熙三十五年六月初八，江寧織造曹寅上請安奏事摺給康熙，康熙朱批「知道了」，這個簡單的問候文書往返數百里，而今可於彈指間完成。

清康熙三十五年六月初八，江寧織造曹寅(曹雪芹的祖父)上請安奏事摺給康熙，康熙朱批「知道了」[1]，這個看似簡單的問候文書，背後的的成本是驛站人馬來回數百里奔波，耗時數日。近年來科技日新月異，網路無遠弗界，只不過我們的文書處理流程竟與古人無異，同樣地傳送紙本，同樣地批示、簽名、用印；但這一切都可藉由線上簽核的施行而有所改觀，原本曠日廢時的文書往返流程，皆可於彈指之間完成。

線上簽核可帶來如此大的便利性，為何尚未普及？背後的因素不外乎在於大眾對於電子文件防偽及驗證制度的信任不足，造成行政單位在此最後一哩裹足不前。回顧以往老祖先在傳統書面文書的防偽驗證也下了不少功夫，如中國古時候調兵遣將用的虎符、西洋用的封蠟章(Wax Seal)火漆印等技術，也是累積多年的使用經驗，才建立了現在所使用的文書制度。這些技術最主要是用來證明文書由誰發出，且事後發文者無法否認發文。邁入電腦化時代，文件電子化後，因為電子文件修改不易留痕跡，防偽及驗證制度變得更加複雜。故要改用線上簽核，捨棄原有紙本簽章，除了要滿足傳統驗證的功能外，還要能驗證電子文件內容是否曾被竄改過。而這一些需求皆可以利用數位簽章技術一一克服。

近10年來，政府積極推動電子化政府計畫，而線上簽核是電子化政府重要的一環。臺灣在民國90年通過電子簽章法[2]，使得國內數位簽章的實行有了法律的依據。在電子簽章法第十條規定數位簽章應依一定之程序製作始生效力，且須由管理機構認可之憑證發放機構 (Certificate Authority (CA) ) 發放之有效憑證為之。為此，行政院研考會依照國際標準規劃之GPKI (Government Public Key Infrastructure)架構，建置GCA(政府憑證管理中心)、MOECA(工商憑證管理中心)、MOICA(內政部憑證管理中心)、XCA(組織及團體憑證管理中心)等官方憑證管理中心，負責各種類憑證發放。目前發行量最大的憑證為內政部所發放的自然人憑證，截至98年7月已發行175萬張。而行政院研考會在97年推動的「電子識別證」，也是採「自然人憑證」與「實體識別證」二合一IC卡片，如下圖所示[3]，正面為機關識別證顯性資料，背面為自然人憑證。有了官方的憑證才能推動各類公文書函線上簽核，達成無紙化的最後一步。

　

本校積極推動線上簽核系統建置，為了讓簽核的文件具有法律效力，規劃方向與政府電子化政府推動方向一致，皆以自然人憑證作為簽核憑證。現已完成「差勤線上簽核系統」，正朝下一步公文及電子表單線上簽核邁進。使用自然人憑證簽核或許有些人會擔心個人隱私被外洩，這一點其實不用太過擔心，因為自然人晶片卡內只存放少數個人資料[4]：包含公開區的公開金鑰、姓名、身分證字號末四碼、憑證序號及私密區的私密金鑰。而且私密金鑰的設計是無法被讀出晶片卡外，且需要輸入正確的PIN code才能使用，以作為資料的加解密之用。以自然人憑證作為簽核的依據能避免系統內的身份被盜用，且不會洩漏個人隱私。

完成了這個「最後一哩」的工程，不論您在世界上的那個個角落，只要連上網路，就能透過線上簽核系統，讓文件批核能在彈指之間完成，作一個名符其實的現代人。

參考資料[1] 故宮文物數位典藏計畫
      http://www.npm.gov.tw/da/ch-htm/prospect04-c.html
[2] 電子簽章法，全國法規資料庫
      http://law.moj.gov.tw/Scripts/Query4A.asp?FullDoc=all&Fcode=J0080037
[3] 行政院研究發展考核委員會--電子化政府推動現況及成果「電子識別證」
      http://www.rdec.gov.tw/ct.asp?xItem=4152195&ctNode=12146&mp=100
[4] 內政部自然人憑證管理中心,
      http://moica.nat.gov.tw/html/index.htm

資料來源

雲端運算平台—Hadoop

作者：周秉誼 / 臺灣大學計算機及資訊網路中心作業管理組碩士後研究人員

---

雲端運算是資料中心因應網路上資訊暴增而提出的服務及管理思維，資訊服務提供者投入資源進行雲端運算的服務及架構開發，Google可說是最大量使用雲端運算的組織之一。Hadoop就是由Google雲端架構得到啟發而開始的開放原始碼計劃，目前有許多組織參與Hadoop的研究開發，並以Hadoop做為雲端運算的平台。

前言隨著網際網路 (Internet) 的發展，及web2.0概念被提出，網路使用者的行為也由單純的瀏覽轉變為創作與分享；另外，行動式的資訊設備也越來越多，為了方便分享及取用，使用者們把資料從個人的電腦中轉移到web服務提供者的資料中心 (Data Center)；而服務提供者為了提供更穩定更迅速的服務，也需要一個新的服務架構，將運算資源及儲存空間更有效率的利用，同時提供服務開發人員更便利的開發環境。

雲端運算 (Cloud Computing) 就是將前述所有的需求整合在一起的概念，一個面向是讓使用者以更加便利的方式使用及取得服務，甚至用最簡單的方式開發新的服務。隨著各種雲端服務產生，對於運算能力及儲存空間的需求，也會驚人地成長，因此雲端運算的另一個面向就是整合組織內部運算資源，以最有效率、最易於管理的方式，提供雲端服務穩定的運算及儲存能量。
以Google為例，許多服務都以雲端運算的形式推出，讓使用者隨時可以取得自己的資料，也能夠透過網路跟其他人分享；還提供了相當便利的開發環境，如 Google App. Engine提供了介面和免費的運算及儲存資源，讓使用者開發各種有趣的web服務。但這些服務需要十分可觀的運算能力和使用者資料的儲存空間，因此，Google開發了許多雲端運算的技術與架構，如MapReduce以分散式運算提供整合的運算資源及減少運算時間、Google File System將大量而分散的儲存空間整合為一個可靠的儲存媒介、BigTable提供高效率的分散式資料庫。這些技術及架構都有一個特點，就是讓服務開發人員不用考慮在這些分散式系統上資料要怎麼放置、運算要怎麼切割，只需要專注在服務的開發就可以了，而資料與運算的切割及分散就交給雲端運算的架構來處理，可說是大大增加了開發服務的速度。

Hadoop計劃Hadoop是Apache軟體基金會 (Apache Software Foundation) 底下的開放原始碼計劃 (Open source project)，最初是做為Nutch這個開放原始碼的搜尋引擎的一部份。Hadoop是以java寫成，可以提供大量資料的分散式運算環境，而且Hadoop的架構是由Google發表的BigTable及Google File System等文章提出的概念實做而成，所以跟Google內部使用的雲端運算架構相似。目前Yahoo!及Cloudera等公司都有開發人員投入Hadoop的開發團隊，也有將近一百個公司或組織公開表示使用Hadoop做為雲端運算平台，Google及IBM也使用Hadoop平台為教育合作環境。
Hadoop中包括許多子計劃，其中Hadoop MapReduce如同Google MapReduce，提供分散式運算環境、Hadoop Distributed File System如同Google File System，提供大量儲存空間、HBase是一個類似 BigTable 的分散式資料庫 (見表一)，還有其他部份可用來將這三個主要部份連結在一起，方便提供整合的雲端服務。

MapReduceMapReduce是一個分散式程式框架，讓服務開發者可以很簡單的撰寫程式，利用大量的運算資源，加速處理龐大的資料量，一個MapReduce的運算工作可以分成兩個部份—Map和Reduce，大量的資料在運算開始的時候，會被系統轉換成一組組 (key, value) 的序對並自動切割成許多部份，分別傳給不同的Mapper來處理，Mapper處理完成後也要將運算結果整理成一組組 (key, value) 的序對，再傳給Reducer整合所有Mapper的結果，最後才能將整體的結果輸出 (見圖一)。

再更仔細地介紹流程中每一步的細節，一開始需要建立一個JobConf類別的物件，用來設定運算工作的內容，如 setMapperClass/setReducerClass設定 Mapper及Reducer 的類別，setInputFormat/setOutputFormat 設定輸出輸入資料的格式，  setOutputKeyClass / setOutputValueClass 設定輸出資料的類型，設定完成後，依設定內容提交運算工作。資料來源會依InputFormat的設定取得，並分割轉換為一組組的 (key, value) 序對，交由不同的Mapper同時進行運算，Mapper要將運算的結果輸出為一組組(key, value) 序對，也稱為中介資料 (intermediate)，系統會將這些暫時的結果排序 (sort) 並暫存起來，等到所有Mapper的運算工作結束之後，依照不同的key值傳送給不同的Reducer彙整，所有同一key值的中介資料的value值，會放在一個容器 (container) 裡傳給同一個Reducer處理，所以在Reducer中可以利用values.next()依序取得不同value值，快速地完成結果整理，再依OutputFormat的設定輸出為檔案。
進行運算的Mapper和Reducer會由系統會自動指派不同的運算節點擔任，所以程式設計時完全不用做資料和運算的切割 (decomposition)，運算資源會由JobTracker分配到各個運算節點上的TaskTracker，並指派不同的節點擔任Mapper和Reducer。

HDFSHadoop Distributed File System (HDFS) 將分散的儲存資源整合成一個具容錯能力、高效率且超大容量的儲存環境，在Hadoop系統中大量的資料和運算時產生的暫存檔案，都是存放在這個分散式的檔案系統上。
HDFS是master/slave架構，由兩種角色組成，Name node及data nodes，Name node負責檔案系統中各個檔案屬性權限等資訊 (metadata, namespace) 的管理及儲存；而data node通常由數以百計的節點擔任，一個資料檔會被切割成數個較小的區塊 (block) 儲存在不同的data node上，每一個區塊還會有數份副本 (replica) 存放在不同節點，這樣當其中一個節點損壞時，檔案系統中的資料還能保存無缺，因此name node還需要紀錄每一份檔案存放的位置，當有存取檔案的需求時，協調data node負責回應；而有節點損壞時，name node也會自動進行資料的搬遷和複製。
HDFS雖然沒有整合進Linux kernel，只能透過Hadoop的dfs shell進行檔案操作，或使用FUSE成為User space下的檔案系統，但Hadoop下的系統都與HDFS整合，做為資料儲存備份及分享的媒介。如前面提到的MapReduce在系統分配運算工作時，會將運算工作分配到存放有運算資料的節點上進行，減少大量資料透過網路傳輸的時間。

HBaseHBase是架構在HDFS上的分散式資料庫，與一般關聯式資料庫 (relational database) 不同。HBase使用列 (row) 和行 (column) 為索引存取資料值，因此查詢的時候比較像在使用map容器 (container)；HBase的另一個特點是每一筆資料都有一個時間戳記 (timestamp)，因此同一個欄位可依不同時間存在多筆資料。
一個HBase的資料表 (table) 是由許多row及數個column family組成，每個列都有一個row key做為索引；一個column family就是一個column label的集合 (set)，裡面可有很多組label，這些label可以視需要隨時新增，而不用重新設定整個資料表 (見表二)。在存取資料表的時候，通常就使用 (‘row key’, ‘family:label’) 或 (‘row key’, ‘family:label’, ‘timestamp’) 的組合取出需要的欄位。

HBase為了方便分散資料和運算工作，又將整個資料表分為許多region，一個region是由一到數個列所組成的，可以分別存放在不同HBase主機上，這些存放region的主機就是region server，另外還有master server用來紀錄每一個region對應的region server；master server也會自動將不能提供服務的region server上的region重新分配到其他的region server上。
HBase也可供MapReduce的程式當作資料來源或儲存媒介，在HBase 0.20版之後提供了TableMapper及TableReducer的類別讓程式中的Mapper及Reducer類別繼承，可以把MapReuce中的 (key, value) 更方便地從HBase中取出和存入。

Web InterfaceMapReduce的JobTracker、HDFS、及HBase都有各自的web監控介面，可以及時觀察目前每個運算工作的運作情況、檔案系統的容量、及資料表和region的使用情況, 讓系統管理者輕鬆地監控大量資源 (見圖二、圖三、圖四)。

　

　

結論Hadoop是目前最常見且實際運用在大規模商業環境上的雲端運算平台之一，強大而完整的基礎架構可以減少大量的雲端架構開發的時間，大量部署時也相當迅速，不但有許多重量級的雲端運算服務提供者正在使用及投入開發，也與Google的雲端環境相似，使Hadoop成為教育訓練、學術研究及雲端服務開發的最佳平台。
雖然有Hadoop這麼便利的雲端運算環境，又有成功的雲端服務可以參考，然而在組織內部導入雲端運算的架構及文化時，仍需做好充分的規劃及時程表，不然將會影響原有服務的穩定及品質，不但不能享受雲端運算帶來的便利，反而徒然增加管理及營運成本，使雲端運算淪為失敗的行銷名詞。

古典玫瑰園 Rose House 集團官網 (古典玫瑰园)

古典玫瑰園 Rose House 集團官網 (古典玫瑰园)

搜索引擎優化 提高排名 如何提高排名

引用

Blog天生就得到搜尋引擎的喜愛，以至於排名總是較前。

◎Blog增加連結機會導致排名較前

不知道您在使用搜尋引擎時是否注意到，許多Blog的某篇文章經常排在搜尋結果前幾筆。這是意外嗎？其實只要理解搜尋引擎運作原理，就很容易知道何以Blog文章這麼討搜尋引擎喜歡。

搜尋引擎運作原理，筆者曾寫過「第三代網路行銷：搜尋引擎行銷」三篇。總結就是：1)增加網站內部網頁彼此連結，有助提高搜尋引擎排名；2)讓別人網站連結到你網站來，有助提高搜尋引擎排名。

一個典型的Blog網站，長得像這個樣子：

http://worker.bluecircus.net/

可以看到很多Blog網站常見的構成元素：日曆，文章分類，文章依月份（或年份）歸檔。每篇文章底部有「上一篇，下一篇」的連結。就是這些，在網站上增加了每篇文章彼此相互連結的機會。

此外，一般Blog還有Trackback 機制。簡言之，當別人在自己寫的文章中提到你的網站上某文章時，他除了建立連結連到你之外，還可以發送一個通知給你的網站，讓你的網站自動建立連結連回到他的網站。

跟外部網站的連結建立是如此自動化。因此我們常看到那些在搜尋結果排名靠前的Blog文章，往往都是被討論被連結最多次的文章。我們終於明白，Blog系統的呈現與運作方式，天生就符合搜尋引擎胃口。

◎搜尋引擎嗜食文字

除上述運作邏輯外，筆者在此補充幾點之前沒提到的搜尋引擎特性：

- 搜尋引擎喜歡文字很多的網頁

如果某個網頁上都是圖形，或者都是大量的連結連往別的網頁，該網頁在搜尋引擎是拿不到高分的，排名也無法靠前；搜尋引擎自有辦法判斷網頁上的文字內容是有意義的文字還是垃圾。

請參考這兩種頁面：

http://www.digitalwall.com/all

http://www.digitalwall.com/scripts/year.asp?txtYear=2006

同樣是站內文章列表，前者網頁僅將標題列出並做連結，後者除此之外還將內文第一段呈現出來在網頁上，讓網頁上具有更多有意義的文字。結果是，後者在搜尋引擎的排名上大獲全勝。

您是否發現，幾乎所有的Blog網頁上都充滿著大量文字。即使是首頁上充斥著文章標題列表，在標題之外也會順帶把第一段呈現出來先讓你看一下。在此，我們又再度看見了Blog在搜尋引擎上的排名優勢。

◎搜尋引擎喜新厭舊

回到我們對企業網站的討論上。相信大家對於「企業網站」一定不陌生，你很容易可以猜到上面一定有「公司簡介」，「產品介紹」，「最新消息」，「聯絡我們」，「企業徵才」，以及此類內容的延伸。

很無趣嗎？是很無趣！也難怪當企業主面對能飛天遁地的 Web 2.0時，完全想不出來該拿自己公司的網站怎麼辦！其中，對於搜尋引擎排名最致命的一點，就是這些內容幾乎不會更新。

一個很久沒有更新的網頁，在搜尋引擎的排名會被新的相關網頁往下擠，因為搜尋引擎喜歡新鮮的內容。一個頁面常常有更動的部分，會被搜尋引擎認為還「活著」。

想來想去，好像只剩「最新消息」會是常更新的部份。一個竅門是，讓你的網站上每個網頁都出現「最新消息」內容。請看範例：

http://www.digitalwall.com/scripts/display.asp?UID=358

頁面上主要內容文章已經寫完，未來很少有機會更新。但網頁右側部分卻可看到有個「近日產業動態」，那些內容是每天甚至每小時都在變動。對搜尋引擎來講，這整個網頁就是新鮮的，因為有變動的部份。

你或許發現了。每一個Blog網站上的每一篇文章或每一個網頁上，幾乎都有最新文章或者最新消息的連結。是的，這是Blog為什麼老是能拿到搜尋引擎排名前幾名的一個原因：他的每個網頁都是最新鮮的。

◎效果才是王道啦！管他幾點零

前些時候筆者和 1.0時代搞網路革命的老戰友工頭堅在 MSN上閒聊，問說是否感覺筆者的網站數位之牆最近在改版。他的第一個反應是：「有，變得 Web 2.0化了」。

這實在是個誤解。筆者網站使用老舊的 ASP 3.0，先前在加入 RSS機制時就已經吃足苦頭。改版目的是改善網站在搜尋引擎的排名（即所謂「搜尋引擎優化」），沒想到越改和當下流行的Blog介面越來越像。

這件事告訴我們，如果 1.0企業網站決心拉高搜尋引擎排名，改到後來會跟Blog很像，而企業主可能從沒聽過 Web 2.0，還被以為是跟風流行。事實上企業主很現實，能帶來客戶的就是好技術，管他幾點零。

此外，如果你公司從來就沒有網站，或者你懶得理解筆者解釋的這麼多原理，建議直接用Blog系統去架設網站會省力得多，反正效果一樣，像筆者這樣搞改版很辛苦。企業網站的 2.0之路，走來並不容易。

資料來源