Microsoft Azure 上有相當多服務可以協助你開發堅固的網站，而針對面向一般消費者的行銷網站（其實適用於許多網站應用情境），Azure 團隊有一個建議的架構圖。

這篇文章就針對這份架構的建議來提供說明。

您也可以參考影片的說明：

流量管理與網站建置

你的客戶可能來自世界各地，或是你希望在多個資料中心做備援，為了要讓用戶的連線可以自動導向鄰近或是還可以正常存取的資料中心，這時你可以使用流量管理員（traffic manager）的服務，讓它設定指向不同資料中心的網站服務，然後將你的網域名稱設定在流量管理員上，接下來要到哪個資料中心就是流量管理員來負責處理，除了可以避免資料放在單一機房上會有服務中斷的疑慮之外，也有負載平衡的效果。

另一方面，Azure 網站服務除了可以自己使用 .NET、PHP、Python、Node.js、Java 來撰寫網站應用程式之外，也可以使用現成的架站工具（如：WordPress, Umbraco 等等）來快速建立網站，若網站需要串接身份驗證的功能，可以直接使用 Azure Active Directory 的服務，直接可以完成 AD、Microsoft、Facebook、Twitter、Google 的帳號身份驗證，不必自己撰寫這部份的程式。

由於是面對消費者的網站，有時候辦一些活動時可能需要臨時增加運算資源來應付暴增的流量，Azure 網站服務可以設定自動延展（Auto scale）的機制，視需要動態增減需要使用的運算資源數量；而若是要處理一些非同步的工作，則可以將這些非同步的工作放在 WebJobs 裡背景執行，方便處理一些非由使用者驅動的工作（如：處理客戶資料、寄送 Email 等）。

根據不同用途處理資料

如果要把使用者在網站上的行為記錄下來，做為日後分析的數據，那肯定是一種大數據（big data）的使用情境，這些資料可以使用 Azure HDInsight 來儲存，這個服務完全基於 Apache Hadoop 的技術架構，而運用 Azure 的雲端技術來提供服務，由於完全是採用 Hadoop 的技術架構，所有基於 Hadoop 架構做的資料處理、分析工具都可以直接使用。

而網站上的靜態檔案部份，不論是網站原本的靜態檔案（CSS、JavaScript、圖片）還是由使用者上傳到網站上的靜態檔案（個人圖片等），都可以運用 Azure 儲存體中的 Blob 儲存體服務來儲存，這些檔案都可以直接透過專屬的 URL 來存取，除了可以分散網站的流量之外，也可以降低網站對本機檔案系統的依賴，有效減輕延展網站的難度；同時，也可以運用 Azure 儲存體對於資料的可得性、易用性來保存檔案。

關聯式資料的部份，當然就可以直接選擇使用 Azure 上的 SQL 資料庫服務，除了不必管理 SQL 伺服器之外，還直接有 HA 架構，並且根據不同的價格方案也能提供完整的備份及還原服務，使用與管理此 SQL 資料庫的方式都與操作在 SQL 伺服器上的資料庫相同。而為了提升資料存取的速度，也可以直接套用 Azure 快取服務來做快取，這個服務是由 Redis 的技術所建立，所以操作使用的方式與 Redis 相同，也能直接使用 Redis 的相關函式庫。

與企業機房連接

你可以使用 Azure 虛擬網路的服務，將 Azure 上的服務與企業機房設定進相同的虛擬網路中，如此一來，企業內的機密敏感資料不必一定要放在雲端，還是可以在自家機房內部，但依然可以透過虛擬網路的設定，讓它能與 Azure 上的服務連接，讓資料只在這個虛擬網路間流動，不必擔心資料洩漏的問題。

擴展服務到行動裝置

如果你還想開發行動裝置的 app 來接觸更多消費者（或是讓消費者多一種方式來使用網站），Azure 的行動服務可以幫你解決開發行動裝置時許多需要伺服器的工作，像是資料同步、身份驗證、（結合通知中樞服務）推播通知等等，讓你可以專心開發 app，而伺服器的部份由 Azure 行動服務做完，並且這些功能都支援 Windows、Android 以及 iOS 裝置，省去許多開發維護的工作。

使用其它服務完成特定工作

如果你要提供影音直播串流、或是隨選視訊（VOD, Video-on-Demand）的服務，這些都可以直接使用 Azure 媒體服務完成，不管是串流還是 VOD 都可以支援各種平台裝置所需要的影音編碼格式，大大減輕了撰寫程式的負擔。而若是要處理其它工作，可以在 Microsoft Azure 市集中找到一些第三方服務來使用，像是寄 Email 的需求，就可以使用市集中的 SendGrid 服務來租用完成。透過這些 Azure 或第三方開發的服務，你的應用程式可以省下很多開發的時程，快速將網站系統上線。

使用 CDN 加速網路存取

當網站系統都開發完成後，除了我們一開始規劃的使用流量管理員來負載平衡、分散流量之外，若想要讓使用者從更接近他的網路節點取得網站內容（靜態內容），則可以使用 Azure CDN 服務來快取網站上的靜態資料、Blob 儲存體內容、媒體服務的影音檔案，舉例來說，離台灣用戶最近的 Azure 資料中心在香港（東亞機房），但若套上 Azure CDN 之後，因為 Azure CDN 的服務有在台灣的節點，所以用戶從 CDN 讀取資料時就是從台灣這裡的節點讀取，比起到香港讀取資料又更快了一點。

這個架構圖只是建構系統上的一個建議，你不一定要照這樣的方式才能建立網站，但總是一種參考架構，同時也可以瞭解 Azure 眾多的服務要如何運用。

感謝北科大劉建昌同學翻譯微軟公司 Azure Data Factory 團隊主管 Mike Flasko於 2014 年 10 月 29 日所發表的文章 http://azure.microsoft.com/blog/2014/10/29/data-factory-public-preview-build-and-manage-information-production-pipelines/

現代企業資料處理的方式相較過往更為多樣化，資料處理往往需要牽涉到多個不同地理位置的資料，面對位於本地與雲端上的資料，甚至較過去更為多樣化的資料型別與更大的資料量，上述原因都會造成資訊系統過於複雜或是多樣化。也因此開發人員必須撰寫大量的客製處理邏輯，以便協調，處理和管理所有產生出來的資料。

我們很高興的宣布，新的 Azure Data Factory 服務正式進入技術預覽階段，可供所有使用者測試和使用。Azure Data Factory 是一個將資料儲存，資料處理，資料搬移運用產生資料管線 (data production pipelines) 方式處理的雲端服務，您僅需要在 Azure 管理網站上透過幾個簡單的步驟，或是使用命令列操作，就能夠建立一個 Data Factory 並且將其與生產的資訊和資源加以結合。在技術預覽階段的 Data Factory 能夠連接到本地端 SQL Server 或是 Azure Storage Blob、Table 與 Azure SQL Database 上的資料。歡迎您將此預覽階段上使用 Azure Data Factory 的心得回饋給我們，我們將會增加更多種資料來源在這項服務上。

關於 Hadoop 巨量資料的處理，在最一開始都是透過 Hive、Pig 或是 C# 等語言撰寫出的 activites 來進行。這些 activites 可以用來清除資料、遮罩資料欄位 (mask data fields) 或是透過各種各樣複雜方式來轉換資料。Hive 和 Pig 所編寫的 activites 能夠在您所建立的 Azure HDInsight 叢集上運行，或者您也能夠讓 Data Factory 來全權管理整個 Hadoop 叢集的生命週期。透過這項方法，您只需要編寫 activites，並且將他們組合成一個管線 (pipeline)，並設定好執行的時程 (execution schedule)，您就完成了所有的設定，不需要再進行額外之 Hadoop 叢集的安裝和管理。Azure Data Factory 也提供了即時的監控儀表板，這意味著您能夠在佈署了資料管線 (data pipelines) 的同時，也能夠立刻在監控儀表板上了解整個資料產出與處理的狀態。

目前您已經可以在 Azure 預覽入口管理網站上啟用 Azure Data Factory 服務。

一旦您在 Azure Data Factory 創建和佈署了管線 (pipelines) 之後，您可以快速評估點對點之間數據傳輸的效率，還能夠精準的找到問題點，並在需要的時候採取矯正措施。在 Azure 預覽入口管理網站上，整個資料管線都是以視覺化方式呈現。用戶可以透過圖像了解管線 (pipelines) 之間的相依性，以及資料如何進行輸入與輸出。您還可以透過監控儀表板，得知作業執行狀態 (job execution)、資料生產的狀況與系統健康狀況等詳細資料。最後，利用資料管線 (data pipelines) 的設定，您可以自動從雲端將巨量資料轉換至本地端的 SQL Server 內，或是將轉換完的資料保存在雲端儲存體上，以供應用程式或分析工具來使用。

透過以下方式，我們可以開始使用 Azure Data Factory

• 按照步驟來建立您的第一個管線 (pipeline)
• 瀏覽更多關於 Data Factory 的產品文件
• 參考 Data Factory GitHub repository 範例
• 若有任何問題，可以到 Data Factory論壇 提問

我們很高興您能夠來試用 Azure Data Factory 服務，並且期待您能夠回饋給我們對於 Data Factory 的使用心得。若您有任何想要告訴我們的想法或是意見，可以到此處來告知我們。

代發北科大劉建昌同學所撰寫之技術文件

傳統使用微軟解決方案之技術人員會透過自建機房伺服器上的 Windows Server IIS 來佈署網站或是網頁應用程式，但是這往往會讓網站承載量受限於實體基礎建設上既有投資，而無法有效率的進行擴充和提高可用性。也因此為了解決這種限制，Azure Website 團隊正式推出了 Azure Websites Migration Assistant 的正式版本協助用戶將現有 Windows Server IIS 上網站與應用程式快速移轉到雲端，您可以透過此網站下載 免費的 Azure Websites Migration Assistant 工具。

Azure Websites 是 Microsoft Azure 所提供的 PaaS ( Platform-as-a-Service ) 服務之一，透過這項服務，開發者只需要專注於網站的開發，而不用擔心建置實體設施的任何問題，即可快速建立一個擁有高擴充性以及高可用性的網站相關服務。

本篇文章透過使用 Azure Websites Migration Assistant，將運行在本地端或遠端伺服器 IIS 上的網站移轉到 Azure Websites 。目前Azure Websites Migration Assistant 支援移轉 IIS 6或更新版本。Azure Websites Migration Assistant 能夠分析您的伺服器 Windows Server IIS 是否安裝完成，並且確認哪些網站是可以移轉到 Azure Websites。

移轉本地端伺服器 Windows Server IIS 上的既有網站

上圖是一個運作在本地端伺服器 Windows Server IIS上的網站

接下來我們可以至 https://www.movemetothecloud.net/ 準備下載 Azure Websites Migration Assistant 工具軟體。Azure Websites Migration Assistant 執行畫面如下圖，用戶可以自行選擇要移轉本地端伺服器的網站還是遠端伺服器上的網站。

本文以移轉本地端伺服器 Windows Server IIS上的網站作為範例。若要移轉遠端伺服器上的網站，則需要輸入伺服器名稱以及使用者帳號與密碼。

Azure Websites Migration Assistant 會找到伺服器IIS根目錄下的所有網站，透過此步驟，您能夠選取IIS上想要移轉的網站。

選取將要進行移轉的網站後，Azure Websites Migration Assistant會產生一個準備報告。

一旦您上傳了移轉準備報告，Microsoft Azure將會開始分析這份報告，並且將結果顯示出來。您需要去仔細閱讀Azure所做出的移轉評估，並且在移轉前確保已經處理所有移轉問題。

若確定移轉問題都解決了，點擊 "Begin Migration"。

Azure Websites Migration Assistant會要求您輸入您的Azure訂閱帳戶。

若您目前還沒有Azure訂閱帳戶，您可以到這裡來申請試用帳號

選擇租用帳戶和訂閱帳號，並且決定要將您移轉的網站和資料庫放置在哪個區域的Microsoft 資料中心。

決定完放置移轉的網站位置後，將需要輸入一個唯一的Azure Websites網域名稱。

在自訂選項中，可以選擇移轉網站的運作規模以及是否重新建立一個 Azure SQL Database 資料庫。

在自訂選項中，可以選取移轉的網站是否要結合 Azure Active Directory，關於更多同步 Azure Active Directory 的資訊，您可以參考此網站。設定完成後，即可以開始進行網站的移轉。

Azure Websites Migration Assistant 會先利用上述步驟設定的 Azure 訂閱帳戶以及移轉目標資料中心的設定，在您指定的 Azure 訂閱帳戶中建立一個 Azure Websites。

此時還尚未將移轉的網站發布到Azure Websites上

點擊 "Begin Publish"，開始將網站發布到 Azure Websites 上。

如下圖所示，原本運行在本地伺服器 Windows Server IIS 上的網站已經成功移轉到 Azure Websites 服務上，並且享有 Azure Website的高擴充性和高可用性。

結論

使用 Azure Websites Migration Assistant，開發者不需要再透過修改程式碼或是重新佈署等方式將網站放到 Azure Website上，而是藉由幾個簡單的步驟，將本地端或遠端伺服器上的網站移轉到 Azure Website 服務上。若想要有更詳細的資訊，您可以透過這篇由Owais Shaikh 所撰寫的部落格，裡面有更多詳細的 Azure Websites Migration Assistant 影片介紹。

相信大家對資料的備份還原一定不陌生，這中間的過程一定也困擾著許多人，難道備份還原一定要這麼麻煩嗎?就不能再簡單一點嗎?

大家的心聲微軟聽到了，所以微軟為大家提供了更簡單、快速，也更安全的方法，就是利用Microsoft Azure所提供的服務，顛覆大家對備份還原的看法。

以下連結為備份還原詳細步驟 :

QNAP NAS : https://onedrive.live.com/redir?resid=7D20775E3D8E95A2!1237&authkey=!AAYhOUOYseW12PY&ithint=file%2cdocx

SQL Server 2014: https://onedrive.live.com/redir?resid=7D20775E3D8E95A2!1239&authkey=!AMYrvJJ-luP9lDc&ithint=file%2cpptx

Windows Server 2012 R2: https://onedrive.live.com/redir?resid=7D20775E3D8E95A2!1240&authkey=!AIRWbeZAlbDklPk&ithint=file%2cpptx

感謝北科大劉建昌同學翻譯微軟公司主管  Tobias Ternstrom 於 2014 年 7 月 12 日所發表的文章 http://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/

在本篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database Premium 版所提供的主動異地備援 ( Active Geo-Replication ) 功能。除了本篇文章的介紹之外，您也可以透過 Channel 9 觀看由 Sasha Nosov 和 Scott Klein 所主講的關於主動異地備援如何運作以及如何確保業務連續性的介紹影片。

何謂業務連續性 ( Business continuity )

所謂業務連續性 ( Business continuity ) 意指當企業在面臨資訊基礎建設或系統發生中斷時，能夠讓資訊服務持續不間斷之機制、策略或是程序。依照資料庫的角度來看，最主要有四種造成服務中斷的狀況 :

1. 本地端硬體或軟體故障時會影響資料庫節點 ( node ) 之運作。( 例如 : 磁碟機故障 )

2. 資料庫內的資料損毀或是遭到刪除 : 此種錯誤通常是因為應用程式的 bug 或人為因素所造成，因此無法透過基礎建設 ( infrastructure ) 方式來偵測問題或排除問題。

3. 資料中心停止運作 : 發生這種原因可能是由自然災害所引起，在這種情況下，需要使用容錯轉移 ( failover ) 的異地備援 ( geo-redundancy )，將現有服務移轉到備用的資料中心。

4. 升級或維護時所發生的錯誤 : 當在進行更新或是維護時，發生了出乎意料的錯誤，此時需要將資料庫還原到更新前的原始狀態。

Azure SQL Database 如何保持業務連續性

從 Azure SQL Database 建立的那一刻起，Azure 系統一直維持每個資料庫都有三個甚至是更多的副本來保護資料庫，資料異動確認 ( updates committed ) 回應前至少已經有兩份資料副本，在高可用性 ( HA ) 措施的保護下，要是發生上述第一點服務中斷的情況，也就是本地端的硬體或軟體發生故障時，仍可以有效的保護資料庫持續提供服務。

而在最新發布的 Azure SQL Database 服務層 ( Basic,、Standard、Premium ) 中，也為了因應上述其他三種資料庫服務中斷情況，提供了確保用戶業務連續性方案。

以下將個別來介紹Azure SQL Database如何在中斷發生的狀況下維持商業連續性 :

資料庫內的資料損毀或是遭到刪除

所有的 Azure SQL Database 資料庫版本 ( Basic、Standard、Premium ) 服務層都提供了自動備份的功能。這項功能專門可以解決因資料損毀或被刪除所造成的錯誤。Azure SQL Database 會每週做一次完整備份 ( full backups )，每天做一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )。而備份的保存期限會依照使用者所使用服務層而有所不同，Premium 版為 35 天、Standard 版為 14 天、Basic 版為 7 天。您可以利用在保存期限內的任何一個備份來還原資料庫，甚至可以還原最近遭到刪除的資料庫，此一自由還原資料至任意時間點的功能可參閱此篇內容。

資料中心停止運作

而針對 Azure 資料中心因為某些原因造成的長時間停擺，Azure SQL Database 各版本提供多種將資料庫備份到另外一個地區資料中心的功能，目前有三種跨資料中心的備援方式可供選擇 :

1. 異地還原功能 ( Geo-restore ) ，無論 Azure SQL Database 的 Basic、Standard 和 Premium 版都能夠透過異地還原功能，在配對的資料中心運用 Azure Storage 內的地理備援複本將資料還原，相關資訊可參閱此篇內容。

2. 標準異地備援 ( Standard geo-replication ) Azure SQL Database 在 Standard 和 Premium 版上擴展了本地端高可用性系統 ( Local HA system ) 能力，用戶可在 Azure 配對之資料中心 ( paired region ) 上建立和維護一個次要資料庫，在平時這個次要資料庫是離線並且是無法讀取的，一旦遇到主資料中心發生停止運作的情況，用戶可以決定是否進行容錯轉移，此時在配對資料中心備援用的次要資料庫方可使用，相關資訊可參閱此篇內容。

3. 主動異地備援 ( Active geo-replication ) Azure SQL Database Premium 版用戶可以選擇此異地備援方式，降低資料遺失風險、並能在最短時間恢復在異地恢復運作的一項災難備援解決方案。主動準異地備援功能可讓用戶選擇多達 4 個地理備援的次要資料庫，而這些次要資料庫可以在任何時候進行���取，並且也可以用於負載平衡 ( Load Balance ) 快速讀取這些副本資料。主動異地備援目前已經進入技術預覽階段，用戶可以公開測試。

升級或維護時所發生的錯誤

使用主動異地備援，您可以建立一個連續的資料庫副本，透過它能夠立即的凍結先前更新或是維護的資料庫和應用程式，而在這個過程之中若是偵測到的錯誤，也能夠快速地回復到這個連續的資料庫副本。

不同的 Azure SQL Database 服務層提供了不同的災難備援解決方案。我們想要強調的是，在不同 Azure SQL Database 服務層之間用戶可以輕易地進行 ”降級” 或是 ”升級”，因此，當資料庫需要進行一些很重要的更新時，您可以先將資料庫從 Standard 版 ”升級” 到 Premium 版，這樣就能夠使用最保險的主動異地備援方式進行系統更新。等到更新完成之後，再將資料庫 ”降級” 回 Standard 版。這樣的好處一方面可以減少成本，另外一方面又能夠提升資料庫在更新時的可靠度。

主動異地備援細節

接下來我們將仔細的描述主動異地備援如何使用於確保業務連續性，並且透過下面的圖示來說明它是如何運作的。

圖一 一個 Azure SQL Database Premium 版的資料庫可以同時在同個區域或是不同的區域上建立最多四個可讀取的次要資料庫

主動異地備援關係 ( Active geo-replication relationships ) 可以透過 Azure 入口管理網站、PowerShell、REST API 來進行管理和建立。在入口網站中，您可以從主要或是輔助的資料庫中管理其備援關係，並且從主資料庫中監控每一個次要資料庫複製的狀況。

圖二 可以使用 Azure 管理入口網站建立和監控多達四個不同資料中心上的次要資料庫

每個資料庫可以建立多達四個可讀取的次要資料庫，每一個都與主資料庫擁有相同的名稱，但是分別建立於不同的伺服器上(伺服器所在的資料中心區域可以相同，也可以不同 )。當次要資料庫第一次被建立時，其狀態為主資料庫當前的狀況，一旦當次要資料庫建立完畢之後，它將會從主資料庫那裡進行連續性的資料複製。

次要資料庫就如同一般的資料庫，在本地端同樣地擁有高可用性系統 ( HA system ) 架構的保護。

圖三 次要資料庫的名稱與主資料庫相同，但是位於不同的伺服器上

不同於 Azure SQL Database 本地端高可用性架構下採用即時的資料複製方式，主動異地備援從主資料庫將資料複製到次要資料庫的資料複製方式是屬於非同步的，當主資料庫正在等待與次要資料庫完成資料交易時，主資料庫不會產生封鎖 ( blocked ) 的狀況。當複製資料到較遙遠的資料中心時，這項改變將可以解決資料複製時發生連線問題 (connection problems) 或網路高延遲 ( high-latency )。

為了確保次要資料庫進行資料交易時，不會造成主資料庫發生瓶頸 ( bottleneck )，因此次要資料庫需要擁有與主資料庫相同 ( 甚至更高 ) 的服務水準等級。

在使用主動異地備援時，次要資料庫是可以讀取的，所以可以支援唯讀 (read-only) 負載之應用情境。當使用者要跨越多個資料庫進行複雜的查詢動作或是需要低延遲時間讀取資料時，這項功能就能夠派上用場。

圖四 : 當某地資料中心發生停擺，可以終止備援關係，並且應用程式將進行容錯轉移到次要位置上。

每個主資料庫的備援關係 ( Replication relationships ) 是可以手動進行調整的，它允許您可以在任何時間點終止複寫。如果您決定終止主區域的複寫，您可以選擇立即終止 ( 這樣會遺失所有尚未執行的交易 )，也可以選擇在所有交易結束之後再終止。如果是資料中心停止運作，連帶影響到主資料庫停止服務，此時仍然可以手動使用容錯移轉。

圖五 : 您可以選擇立即停止或是等待所有數據交易處理完之後再停止

注意 : 只有主資料庫才有提供上述兩種停止作業方式。

若是從次要資料庫終止備援關係的話，備援關係將立即終止，並且您將會失去尚未被複製的資料交易。而會失去多少將取決於主資料庫在故障的時間點所做的備份以及在連線中緩衝多少資料交易。當您決定是否要終止備援關係時，您需要考慮到資料遺失的問題以及是否資料庫是否需要再進行備份。

圖六 : 若是從次要資料庫上進行停止異地備援的動作，就只能夠選擇立即停止

一旦您終止了主資料庫與次要資料庫間的備援關係，此時次要資料庫將成為一個可以正常讀寫的資料庫，同時您也擁有這個資料庫完整的存取權限。由於次要資料庫與主資料庫擁有相同的名稱 ( 但是在不同的伺服器上 )，因此您需要在應用程式上重新配置連接字串 ( Connection String )。若您進行了容錯移轉，這將需要在新的資料庫上重新建立與先前主資料庫相同的地理備援關係，以確保在容錯轉移之後，仍繼續擁有地理備援或負載平衡的能力，滿足業務連續性上的需求。

圖七 : 在終止次要資料庫的備援關係之後，新的主資料庫也需要建立地理備援關係來保護資料庫，並且也支援負載平衡

主動異地備援可以被整合進任何應用程式架構中，但是在某些應用架構中使用它是有風險存在的。更多關於此主題的資訊請參照本文。

結論

主動異地備援不僅提供了強大的地理備援功能來保護資料庫不受到資料中心停擺所影響，更能夠使用在不同的商業連續性方案。主動異地備援目前已進入技術預覽階段，只有 Azure SQL Database Premium 版方有提供。

您可以透過此文章了解更多關於 Azure SQL Database 使用主動異地備援來維持業務連續性，或是觀看在Channel 9上由 Sasha 和Scott 主講關於主動異地備援如何支援實際業務的影片。我們將認真聽取您的意見，請您放心使用它，並且告知我們您的想法。