Microsoft Azure 的正體中文官方消息，以及在台灣的案例研究。
本文章是翻譯微軟公司 Azure SQL Database 群組程式經理 Sanjay Nagamangalam 於 2014 年 12 月 22 日所發表的文章
http://azure.microsoft.com/blog/2014/12/22/client-tooling-updates-for-azure-sql-database/
隨著 Azure SQL Database 最新預覽版本的發佈，我們也非常興奮地宣布讓主要的用戶端工具也支援 Azure SQL Database 這項服務。現在 SQL Server 2014 Management Studio (以下簡稱: SSMS) 這項工具將支援 Azure SQL database，包含最新版本的 SQL Database Update V12 (預覽版)。我們已經從橫跨產品面的改變，讓這些產品能夠在不同平台上面延伸相關的功能，像是我們已經試著從支援完整資料庫物件導覽功能 (例如：表單設計到匯入匯出功能等) 延伸到 Azure SQL Database。將這些功能特性導入到 SSMS 工具後，將能提供使用者或管理人員一種簡單又熟悉的環境，讓他們能夠輕鬆地管理雲端服務。
更多有關 SSMS 的細節資訊在這裡。
除此之外，隨著預覽版本的發表，我們也將 SQL Server database tooling 整合到 Visual Studio 裡。像是 SSMS 這次更新的版本則包含了一組提供給 Azure SQL Database 服務的工具包 (Toolset)、也同時支援最新版本的 Azure SQL Database Update V12 (預覽版)。
更多有關 Azure SQL Database Update V12 (預覽版) 的細節資訊在這裡。
隨著這些用戶端工具的更新，您現在可以隨意探索與管理 Azure SQL Database，像是在一個高生產力環境下，佈署最新版本的 Azure SQL Database 服務，並且，提供一個熟悉的操作環境給我們的企業 (或一般) 用戶。您可以立即開始試用，並且告訴我們您的意見。
本文章是翻譯微軟公司Azure儲存體原則程式經理Sirius Kuttiyan於2014年12月11日所發表的文章
http://azure.microsoft.com/blog/2014/12/11/introducing-premium-storage-high-performance-storage-for-azure-virtual-machine-workloads/
我們非常地興奮來公布微軟Azure頂級儲存體磁碟(Microsoft Azure Premiun Storage Disks)預覽版的消息。隨著全新頂級儲存體簡介的內容，微軟Azure現在已經可以提供兩種不同類型的儲存體規格: 頂級儲存體和標準儲存體。頂級儲存體內的資料是存放在目前最新技術的固態硬碟(Solid State Drives, 俗稱 SSD)內，而標準儲存體的資料則是存放在一般硬碟(Hard Disk Drives, 俗稱HDDs)內。
頂級儲存體是針對Azure虛擬機器運作時，所需要持續性的高效率與低延遲需求所特別設計的規格。這讓此規格的儲存體能夠滿足對資料進出(Input/Output, I/O)大小敏感的SQL伺服器。頂級儲存體目前僅提供Azure虛擬機器儲存資料所需的硬碟使用之。
您可以在各種頂級儲存體硬碟規格中，挑選並佈署一個滿足您需求的頂級儲存體硬碟。接著您將可以將這些儲存體硬碟掛載到某一台虛擬機器上，已提供給您的應用程式使用。並且，可提供每一台虛擬機器最大32 TB的儲存空間、高達50,000 IOPS(Input/Output per second)、和在讀取模式下，可滿足小於1毫秒(millisecond)的延遲。
隨著頂級儲存體的推出，Azure能協助您將企業的應用程式-例如: SQL伺服器、Dynamics AX、Dynamics CRM、Exchange伺服器、MySQL以及SAP企業套件(Business Suite)等-真正搬移到雲端平台上。
目前，頂級儲存體仍在預覽版本(Preview)，若欲註冊並使用Azure頂級儲存體預覽版，請參考預覽功能。
頂級儲存體的優點
我們設計這項服務是針對強化企業內有許多工作負載的應用程式需要大量且快速的資料寫入與輸出(Input/Output, I/O)的特性所設計的。同時也提供如同本地端備援儲存體(Locally Redundant Storage, LRS)的高備援機制。
頂級儲存體硬碟提供高達每秒5,000次資料輸入與輸出(IOPS)的效能，以及依據不同硬碟容量所能達到的每秒資料傳輸量(最高可達每秒200 MB)。針對IOPS的計算，我們採用每IO單位大小為256KB的條件，若資料小於256KB，則以一個IO單位計算之；若資料大於256KB，則以多個IO單位計算之。
您必須依據應用程式所需效能與儲存容量的需求來選擇相對應的硬碟容量。在頂級儲存體預覽版本中，我們提供三種不同硬碟容量供您選擇，如下：
硬碟規格
P10
P20
P30
硬碟容量
128 GB
512 GB
1024 GB
每顆硬碟的IOPS
500
2300
5000
每顆硬碟的傳輸量
100 MB/sec
150 MB/sec
200 MB/sec
詳細資料請參考Premium Storage Overview
若是選用D系列的虛擬機器，並且掛載多顆頂級儲存體以及網路頻寬使用率達到限制上限時，您將可以獲得最大的效能。例如：選擇一款16核心的D系列虛擬機器，您將可掛在最高32 TB的頂級儲存體硬碟，並最高可達50,000 IOPS。欲進一步了解不同虛擬機器規格可獲得的硬碟頻寬資訊，請參考Azire的虛擬機器和雲端服務大小。
耐用度(Duribility)
資料的耐用度是衡量儲存體服務好壞的一項重要指標。Azure客戶們的應用程式都可以確保資料能夠長期保存，以及當系統發生錯誤時，具有高容錯能力的服務。這也是為什麼我們將本地端備援儲存體技術應用在頂級儲存體服務中。在同一個資料存放的區域內，頂級儲存體的資料能夠保有三份複寫。
我們也您使用儲存體的其他服務來建立快照(Snapshot)，並且將這些快照複製一份到標準的異地備援儲存體(Geographically Redundant Storage, GRS)，以確保這些快照資料也擁有異地備援。
特定規格的虛擬機器
我們也即將推出特殊規格的虛擬機器來滿足頂級儲存體的高效能。這些虛擬機器將搭配最新快取技術以提供讀取模式下的超高低延遲效能。為了能夠享受頂級儲存體的效能，您也必須採用這些特殊規格的虛擬機器。目前，僅有D系列的虛擬機器支援掛載頂級儲存體。
當然，這些虛擬機器也支援掛載標準的儲存體。因此，您可以使用一台D系列的虛擬機器，同時混合使用頂級與標準版的儲存體，並且依據您的需求來調整資料存取的效能和成本。
定價
全新的頂級儲存體定價部分，請參考Azure儲存體定價。服務預覽期間，使用頂級儲存體服務將可享受最高50%的優惠。
開始使用
第一步: 註冊服務
開啟Azure預覽功能網頁，點選頂級儲存體的"試試看"後，透過您帳號內的註冊來使用此服務。當您申請頂級儲存體服務審核通過後，您將會收到一封電子郵件。因為，我們會一一處理欲申請此服務的使用者，所以，服務審核的速度會較為緩慢，請您耐心等候通知。
第二步: 建立一個儲存體帳號
當您取得審核通過的通知後，您將可以登入微軟Azure主控台預覽版，並建立一個全新的頂級儲存體帳號。
目前頂級儲存體僅有以下地區可以使用，如下:
第三步: 建立一個D系列虛擬機器
您可以在微軟Azure主控台建立，或是透過Azure PowerShell SDK 0.8.10或更新的版本建立之。以下是使用PowerShell建立一個D系列虛擬機器，並且掛載您的頂級儲存體帳號的範例，如下:
$storageAccount = "yourpremiumccount"
$adminName = "youradmin"
$adminPassword = "yourpassword"
$vmName = "yourVM"
$location = "West US"
$imageName = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201409.01-en.us-127GB.vhd"
$vmSize = "Standard_DS2"
$OSDiskPath = "https://" + $storageAccount + ".blob.core.windows.net/vhds/" + $vmName + "_OS_PIO.vhd"
$vm = New-AzureVMConfig -Name $vmName -ImageName $imageName -InstanceSize $vmSize -MediaLocation $OSDiskPath Add-AzureProvisioningConfig -Windows -VM $vm -AdminUsername $adminName -Password $adminPassword New-AzureVM -ServiceName $vmName -VMs $VM -Location $location
若您的虛擬機器需要更多硬碟空間，您可以透過以下範例掛載一個全新硬碟至目前的D系列虛擬機器中，如下:
$storageAccount = "yourpremiumaccount"
$vm = Get-AzureVM -ServiceName $vmName -Name $vmName
$LunNo = 1
$path = "http://" + $storageAccount + ".blob.core.windows.net/vhds/" + "myDataDisk_" + $LunNo + "_PIO.vhd"
$label = "Disk " + $LunNo Add-AzureDataDisk -CreateNew -MediaLocation $path -DiskSizeInGB 128 -DiskLabel $label -LUN $LunNo -HostCaching ReadOnly -VM $vm | Update-AzureVm
如果您想要透過自己虛擬機器映像檔案來建立新的虛擬機器，您首先應該要將映像檔案或硬碟上傳至頂級儲存體帳號內，接著再使用該檔案建立虛擬機器。
總結與相關連結
我們非常興奮地公布全新液態硬碟為基礎的頂級儲存體服務，提供更加強化的虛擬機器效能與大幅提升的資料讀寫能力。如同我們始終努力的，無論是透過本篇文章的留言、在Azure儲存體MSDN論壇、或是直接來信至mastoragequestions@microsoft.com，我們非常樂意聽到您的意見與回饋。
請瀏覽以下資訊以獲得更多相關資訊:
Azure Backup 已支持最新的 Windows Server 操作系统，例如 Windows Server 2008 R2、Windows Server 2012 和 Windows Server 2012 R2。如今 Azure Backup 將該服務進一步擴展，已可為 Windows Server 2008 64 位元的操作系統提供服務。
Azure Backup 能夠將內部部署的 Windows Server 2008 以最高效、安全的方式將資料長期備份至 Azure。Azure Backup 也能夠與系統中心資料保護管理器無縫接軌，直接從 Windows Server 2008 進行應用程式的備份。下表列出了 Windows Server 2008 操作系統工作負載的不同保護方式：
操作系統
支持的工作負載
使用的技術
Windows Server 2008（64 位元）
文件和資料夾
Azure Backup
文件和資料夾、Hyper-V 虛擬機器、MS-SQL 資料庫
系統中心資料保護管理器和 Azure Backup
欲瞭解更多關於 Azure Backup 使用的詳細步驟，請參閱 Windows Server 於公有雲上的備份還原服務課程，若您對於 SQL Server or QNAP 的備份還原有興趣，則可參閱這篇文章，亦提供了詳細步驟。
Windows Server 2008 的其他先決條件
先決條件
下載位置
Windows Server 2008 Service Pack 2
Windows Server 2008 SP2 下载
.Net 3.5 Framework
.Net3.5 下载
現在您已經了解如何使用 Azure Backup 為您的 64 位元 Windows Server 2008 提供備份還原服務，接下來您可以參考以下內容來快速開始使用 Azure Backup：
本文原始發布於「TechNet 台灣部落格」
感謝北科大劉建昌同學翻譯微軟公司 Azure Media Services 主管 Adarsh Solanki 於 2014 年 9 月 10 日所發表的文章
http://azure.microsoft.com/blog/2014/09/10/introducing-azure-media-indexer/
Internet 視訊應用在目前的網路環境中快速增長，依據 Cisco VNI Forecast 的預測，網路視訊所產生的網路流量在 2014 年佔所有消費者網路流量的 70%，到了 2018 年則會增加到 79%。就現今網路環境而言，網路視訊已隨處可見，視訊應用快速增長也衍生出了一些問題。
Internet 網路的設計原是基於文字檔案之應用，也因此要在 Internet 上搜尋文字資料是相對較容易，技術也較為成熟，但是另一方面，視訊檔案則需要透過複雜的分類系統和大量人工標記資料 (manually-tagged)，才能夠以文字來進行搜尋。
若是有一種方法可以自動擷取影片中有意義的語音資料，對影片搜尋而言將會相當便利。Azure Media Indexer 是為一個媒體處理器( Media processor ) 雲端服務，透過微軟研究院 ( Microsoft Research ) 的自然語言處理 ( natural language processing ) NLP 技術，將影片內容中有意義的語音，轉換成一個關鍵字檔 ( keyword file ) ( XML )、一組隱藏式字幕檔 ( SAMI/TTML ) 與一個二進位索引檔 (AIB)。
隨著多媒體內容在網路環境下的快速發展，使用者更加重視內容的可閱讀性，也因此許多影片都會用到字幕來作呈現，但是現階段所有影片都是透過人工的方式來建立字幕，這樣不僅費時且成本也相當的高。Azure Media Indexer 的語音識別引擎會自動建立一個附有時間標籤的字幕檔，裡面包含了輸入影片之英文口語單字，透過這種自動化轉換，我們可以將以往需要大量人工工時的工作轉變為全自動化的工作。同時也利用 SQL Server 或是 Apache Lucene/Solr 之類的索搜尋引擎來搜尋影片中某個重要片段，使用者可以相當簡單地透過搜尋文字的方式來找到影片中特定時間的內容。透過上述的方法，可以大幅減少搜尋影片內容的複雜度。
接下來透過一個簡單的範例，來介紹如何透過 Azure Media Indexer 來處理您的媒體文件。
利用 Azure Media Indexer ，使用者可以在本地端或是網路上的文件資料中建立索引。而在本範例，我們將把本地端的媒體文件上傳到 Azure Media Service，再透過 Azure Media Indexer 來建立索引。
在此教學中，我們利用 Channel9 的影片來進行示範。將本影片儲存為 MP4檔，並且重新命名為 "Index.mp4" 從存放C:\Users\<<USERNAME>>\Videos\Index.mp4。
完整的程式碼範例可以在此連接下載。
在 Visual Studio 2013上建立一個C#主控台應用程式專案 (File > New > Project or Ctrl+Shift+N)
接下來，利用 NuGet 封包管理來安裝 "Azure Media Services .NET SDK"
( 在專案上點擊右鍵，選取 NutGet，並且在搜尋欄位上搜尋 "Azure Media Services .NET SDK" )
打開專案檔上的App.config檔，並且將下方程式碼加入至appSettings欄位上。
(要注意的是，要確保輸入的媒體服務名稱和金鑰是存在並且有效的)
資產是 Azure Media Services 用來儲存媒體檔案的容器 (container)，一個資產內部除了包含了媒體檔案的本身之外，還包含了串流所需要用到的檔案。在本範例中，您將建立一個資產檔案，並且透過.NET SDK來儲存視訊。同時您也可以利用 Azure 管理網站來更新您資產內的檔案。
首先您需要將以下程式碼加入到主控台應用程式的 Program.cs。
您將需要宣告一個 CloudMediaContext 物件來建立與Azure Media Service 的連線。透過這個步驟，將允許您在Azure Media Service上建立一個新的資產(Asset)，並且上傳本地端的文件作為資產檔案(Asset File)。
首先，在 Program.cs 裡增加以下程式碼，此程式碼將告訴主控台應用程式要在哪裡找到來源檔案，並且將檔案輸出在哪裡。
接下來您需要建立一個主控台動作 ( job )，並且加上以下程式碼 :
透過以上程式碼，您已經在 Azure Media Service 上面建立一個資產 ( Asset )，並且上傳了一個本地端的檔案。下一個步驟，您將建立一個參考，這個參考可以讓Azure內容檢索處理器做為檢索的參考數值。在 Azure Media Service上的工作 ( jobs ) 一個或多個任務( Tasks ) 組成，專門用來指定特定處理動作 ( 編碼encoding、包裝 packaging 等.....) 的細節內容。
透過建立索引工作中的任務，在其中可以設定一些在進行索引工作時會用到的參考資訊，在本範例中，您將建立一個作為索引任務的設定檔 "default.config"，裡面將包含了一些有用的資訊可供索引工作參考。
Azure Media Indexer 參考的任務設定檔為一個XML檔案，裡面包含了幾項關於檢索檔案的基本資訊或是關鍵字，利用他們可以來提高語音辨識的精準度。
在現有版本的 Azure Media Indexer 上，允許在配置檔中描述媒體文件的標題以及其內容大綱，透過這樣的任務配置，可以讓自然語言處理引擎 ( adaptive natural language processing engine ) 基於已知的主題來增加翻譯的詞彙，讓結果更加精準。
例如 :
如果您有一個關於 "Geico" 的影片，透過在任務配置檔上輸入此標題，就能夠減少在翻譯文章時會出現"guy co"這種錯誤發生。
或者在檢索影片時，當中提到 “aortic aneurism (主動脈動脈瘤)”，正常情況下有可能會被誤解為“A or tick canner is um" 這種不知所云的翻譯，此時若是加入任務配置，在標題或是大綱內容提供 “hypertension (高血壓)” 的資訊，這將會提高搜尋引擎的準確度。
在專案點擊右鍵，新增一個XML檔案作為任務配置檔，並且新增以下程式碼，取名為"default.config"。在本範例中，我們使用Channel9上關於範例影片的標題與大綱敘述作為配置檔的內容。
建立完任務配置檔後，返回 Program.cs 檔案，並且修改 ConfigurationFile 字串的位址。
在上個步驟中，我們已經建立了一個任務配置檔供檢索工作參考，現在我們將繼續建立未完成的工作。
透過下列程式碼，我們將建立一個工作，並且啟用這個工作裡的任務。
接下來，我們在主程式的最底部新增一個輔助方法，用來給定一個最新版的媒體索引器。
透過以上的程式碼，您已經提交了一個主控台工作，這個工作將會把您本地端的媒體文件上傳到 Azure Media Service上，並且透過 Azure Media Indexer 進行處理。
我們還可以透過以下的程式碼，讓您可以隨時追蹤主控台工作的進度。
輸出的檢索檔案一共有四個 :
1. SAMI格式的字幕檔
2. 附有時間標籤的 TTML檔
3. 關鍵字檔 (XML)
4. 音訊索引 blob (AIB)
其中 SAMI 和 TTML 文件包含了視訊的時間標籤，而 XML 檔裡面包含了索引時所使用的關鍵字。
透過本篇範例，您將會得到以上四個輸出的檔案，透過上述四個檔案，您可以與您的媒體文件做結合，即可輕鬆地得到媒體文件的內容。
這篇範例並沒有包含所有 Azure Media Indexer 功能，例如支援多個文件的索引，或是在網路上利用 URL 取得索引檔。
Azure Media Indexer 並非針對即時翻譯需求而設計的，語音辨識所需時間約為影片長度的三倍，Azure Media Indexer 著重於辨識的精確度而非強調辨識速度的應用情境。
完整的範例您可以透過以下連接下載
最短的工作持續時間為五分鐘，小於此時間的工作持續時間將會被當成五分鐘，並且依照其計費標準計費。
前一陣子 Microsoft Azure 宣佈了支援 Docker 的消息（同時還有新的 Windows Server 的 docker container），同時，Microsoft Azure 的跨平台命令列工具也支援了直接建立 Docker host 的操作，這篇文章簡單說明一下建立的流程（示範的平台是 Mac OSX，選擇 Ubuntu Linux 14.04 LTS 作為 Docker Host 的作業系統）。
azure account download
azure account import <檔案>
接下來就可以準備建立 Docker Host 的虛擬機器了，這裡因為選擇 Ubuntu Linux 14.04 LTS，所以我們先使用 azure vm image list | grep Ubuntu 的指令來看一下 Azure 上的虛擬機器映像檔名稱。（因為直接使用 vm image list 會列出所有的映像檔，所以後面接 pipe 到 grep 篩出 Ubuntu 關鍵字的）
azure vm image list | grep Ubuntu
圖: 尋找 Azure 上關於 Ubuntu Linux 的映像檔名稱
找到了要安裝的 Ubuntu Linux 的映像檔，就可以用來建立虛擬機器，所幸目前的命令列工具已經可以在建虛擬機器的同時建立 Docker Host，只要下這樣的指令：
azure vm docker create -e 22 --location 'East Asia' my-docker-host "b39f.....30GB" 帳號 密碼
這行指令開一個 SSH 聽 port 22（-e 22），然後在東亞的機房建立虛擬機器（--location 'East Asia'），這個虛擬機器的名稱叫 my-docker-host，然後代入映像檔全名，最後再加上登入虛擬機器的帳號密碼完成。
下完指令後 Azure 就會開始建立虛擬機器，這時只要靜待數分鐘等它配置及啟動完成，而這個虛擬機器除了 port 22 的 SSH 之外，就會開 docker 預設的 port 4243 來操作，你可以試試看這個指令來確認 docker host 的狀態：
docker --tls -H tcp://my-docker-host.cloudapp.net:4243 info
如果正確的話應該就會回覆像這樣的訊息：
就這樣簡單的幾個步驟，你就很快建立好一個 docker host，然後試著把 docker container 丟上去運作了。
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 或第三方開發的服務，你的應用程式可以省下很多開發的時程，快速將網站系統上線。
當網站系統都開發完成後，除了我們一開始規劃的使用流量管理員來負載平衡、分散流量之外，若想要讓使用者從更接近他的網路節點取得網站內容（靜態內容），則可以使用 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
我們很高興您能夠來試用 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上的網站
接下來我們可以至 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 ) 意指當企業在面臨資訊基礎建設或系統發生中斷時，能夠讓資訊服務持續不間斷之機制、策略或是程序。依照資料庫的角度來看，最主要有四種造成服務中斷的狀況 :
1. 本地端硬體或軟體故障時會影響資料庫節點 ( node ) 之運作。( 例如 : 磁碟機故障 )
2. 資料庫內的資料損毀或是遭到刪除 : 此種錯誤通常是因為應用程式的 bug 或人為因素所造成，因此無法透過基礎建設 ( infrastructure ) 方式來偵測問題或排除問題。
3. 資料中心停止運作 : 發生這種原因可能是由自然災害所引起，在這種情況下，需要使用容錯轉移 ( failover ) 的異地備援 ( geo-redundancy )，將現有服務移轉到備用的資料中心。
4. 升級或維護時所發生的錯誤 : 當在進行更新或是維護時，發生了出乎意料的錯誤，此時需要將資料庫還原到更新前的原始狀態。
從 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 主講關於主動異地備援如何支援實際業務的影片。我們將認真聽取您的意見，請您放心使用它，並且告知我們您的想法。
感謝北科大劉建昌同學翻譯微軟公司 Azure 團隊主管 Khalid Mouss 於 2014 年 10 月 13 日所發表的文章 http://azure.microsoft.com/blog/2014/10/13/accessing-and-using-azure-vm-unique-id/
Azure 團隊最近新增了一項功能，讓開發人員可以取得一個代表 Azure Virtual Machine 絕對唯一的 ID。
這個唯一的 Azure VM ID 是一個 128 位元的識別碼，它可以透過 Azure IaaS 虛擬機器的系統 BIOS ( SMBIOS ) 來進行編碼與儲存，並且能夠使用虛擬機器上的 BIOS指令讀出。這個識別碼不管是在 Azure 上或是本地端 ( on-premises ) 皆可以使用，並且幫助您在 Azure IaaS 佈署上用於管理授權 ( licensing )、回報 ( reporting )、追蹤 ( tracking ) 等需求。
當許多獨立的軟體供應商與合作夥伴在 Azure 上佈署了應用程式，並且需要驗證它是否執行於某個特定虛擬機器內，會需要在虛擬機器的生命週期 ( lifecycle ) 中清楚知道這個虛擬機器是在何處執行? 透過此一唯一識別碼，我們可以得知目前虛擬機器是執行於 Microsoft Azure、本地端、或是其他雲端業者平台。這個唯一的識別碼可以用於檢測軟體是否有適當的授權 ? 或是將虛擬機器的基本資料關聯到它執行所在的平台，藉此協助在其平台上做適當的參數設定。
這個唯一的識別碼不能夠被修改，只能進行讀取查詢，雖然只有在 2014 年 9 月 18 日之後建立的虛擬機器才預設擁有這項功能，但是在 2014 年 9 月 18 日之前建立的虛擬機器可以透過將虛擬機器重新啟動來得到這項功能。
虛擬機器的唯一的識別碼 ( Azure Unique VM ID ) 在下列情況下皆不會改變 :
但是，若虛擬機器是一個快照 ( snapshot )，並且用來建立一個新的執行個體 ( instance )，此時的虛擬機器的唯一的識別碼 ( Azure VM ID ) 是會改變的。
如果在這項功能發行前已經建立好虛擬機器並且運行了，您可以重新啟動 VM，藉此來得到這個唯一的 ID。而重新設定之後，您就可以使用它了。
您可以透過以下步驟的操作，在您的虛擬機器中獲得虛擬機器的唯一的識別碼 ( Azure VM ID ) :
1. 建立一個虛擬機器 ( 只有在2014年9月18日之後建立的虛擬機器才預設擁有此功能 )
2. 連線至虛擬機器
3. 查詢虛擬機器的Unique ID
上圖是利用 PowerShell 指令與查詢結果
上圖是指令與查詢結果
由於位元組 Big Endian bit ordering 因素 ，因此上圖的唯一識別碼實際應該如下:
98 F9 D8 26 - 4E 3D - XXXX - BF B6 B5DE5F108440
不管您在 Azure 虛擬機器上放置甚麼應用程式，您皆能夠透過上述方式得到一個唯一的識別碼。
再次提醒您，若您在此項功能釋出前就已經建置好虛擬機器的話，只要透過重新啟動虛擬機器，一樣也能得到此項功能。
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 3 日所發表的文章 http://azure.microsoft.com/blog/2014/09/03/azure-sql-database-standard-geo-replication/
在這篇文章中，我們將繼續針對 Azure SQL Database 各種業務連續性 ( Business Continuity ) 方案作介紹，以及討論最近 Azure SQL Database 新釋出的標準異地備援 ( Standard Geo-Replication ) 功能。標準異地備援功能允許您從主要資料庫以非同步 ( asynchronously ) 的方式將已認可的交易 ( committed transactions ) 複製到預先設定妥的備援資料中心 ( Azure Regions )。
在深入討論之前，我們先整理 Azure SQL Database 所有確保業務連續性之解決方案，並且討論它們在各 Azure SQL Database 服務層級下的狀況。您可以在此篇文章中找到所有關於 Azure SQL Database 各服務層的詳細資訊。
在先前關於主動異地備援 ( Active Geo-Replication ) 的文章中，已經先行定義了業務連續性的挑戰目標，而在這裡我們來快速複習一下幾個重要的概念 :
下表顯示了不同服務層之間的業務連續性差異 :
業務連續性與災害復原 ( BCDR, Business Continuity and Disaster Recovery ) 相關功能
Basic
Standard
Premium
即時還原
( Point in Time Restore )
過去 7 天內的時間點
過去 14 天內的時間點
過去 35 天內的時間點
異地還原
( Geo-Restore )
RTO<24小時
RPO<24小時
標準異地備援
( Standard Geo-Replication )
不支援
RTO<2小時
RPO<30分鐘
主動異地備援
( Active Geo-Replication )
RTO<1小時
RPO<5分鐘
選擇哪一種業務連續性與災難恢復 ( Business Continuity/Disaster Recovery ，BCDR ) 解決方案的關鍵因素往往與應用程式效能有關，如果您的應用程式的資料更新率 ( rate of updates ) 較低，處理的資料量也較少時，Azure SQL Database 所提供最基本異理還原 ( Geo-Restore ) 將是適合您的方案。若應用程式需要處理較大的資料量，並且對於 RPO 以及應用程式效能要求較高時，就需要使用標準異地備援 ( Standard Geo-Replication ) 來符合您的需求。至於最高階的主動異地備援 ( Active Geo-Replication ) 則是針對需要最低 RPO 以及處理大量資料異動量之需求所提供的解決方案。
當您從 Azure SQL Database Basic 服務層升級到 Premium 服務層時，您能夠選擇的業務連續性與災難恢復 ( BCDR ) 解決方案也就越多。Azure SQL Database 高階版本包含了所有入門版本服務層級的全部 BCDR 功能。
現在讓我們進一步了解標準異地備援的用戶驗經驗，以及它不同於主動異地備援之處。
首先，標準異地備援與主動異地備援是建立在相同的技術上，但是標準異地備援較適合資料密集寫入 ( write-intensive ) 量較少的應用情境。一般而言以下幾點考量會讓用戶決定該採用標準異地備援 :
標準異地備援 ( Standard Geo-Replication ) 相較於主動異地備援 ( Active Geo-Replication ) 簡化如下:
圖一 : 為標準異地備援的典型配置。一個資料庫可以在配對的備援資料中心 ( DR paired ) 內擁有一個離線狀態的備援資料庫
如您所見，標準異地備援的重點就是讓 Azure SQL Database 資料庫從大規模的故障區域中盡速恢復，並且維持正常的運作。但是有時候要做到這點，可能還是需要更強而有力的主動異地備援 ( Active Geo-Replication ) 來完成。以下表格總結了兩者使用的差異 :
方案
(Standard Geo-Replication)
(Active Geo-Replication)
處理區域災害
( Regional disaster )
Yes
災害復原演練
(DR Drills)
線上應用程式更新
No
線上應用程式搬移 ( relocation )
讀取負載平衡
( Read load balancing )
既然 Azure SQL Database Premium 版能夠同時支援標準異地備援和主動異地備援。那在甚麼情況下您要選擇的是標準異地備援，而不是更為強大的主動異地備援呢 ?
標準異地備援被設計為一個較為簡單且便宜的災害還原解決方案 ( DR solution )，特別適合用來處理資料更新率較低的應用程式。如果 Azure SQL Database Premium 版資料庫是被用來處理大批讀取導向 ( read-oriented ) 的工作負載時，就相當適合使用標準異地備援。
當使用標準異地備援時，您無法選擇備援資料庫的資料中心位置，也不會如同主動異地備援般擁有四個具備讀取權限的備援資料庫，也無法完全控制在何時何地進行容錯移轉。但是相對的，使用標準異地備援讓您得到一個由 Microsoft 控制，較為簡單的監測方式以及容錯移轉流程。對於 Azure SQL Database Premium 用戶而言，標準異地備援和主動異地備援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版資料庫去建立一個離線的標準異地備援資料庫，同時您仍可以利用主動異地備援功能，建立多個可讀取的備援資料庫用於讀取負載平衡，以應付高密集讀取的應用情境。
標準異地備援是專門為資料庫提供從災害停機中恢復的解決方案。除非有一個 Azure SQL Database 在主要的託管區域停止運作，否則您將無法啟動容錯移轉到配對資料中心內的備援 ( secondary ) 資料庫。也就是說若您使用標準異地備援，倘若發生用戶應用層級的資料庫停止運作，用戶是無法自行手動進行的容錯移轉，若有這類需求，用戶應該選擇使用主動異地備援。
若有一個 Azure 資料中心發生長時間停機的狀況時，微軟會針對使用 Azure SQL Database 標準異地備援的資料庫進行容錯轉移。這項措施的目標，就是要在 Azure SQL Database 停機發生後的一小時之內啟動容錯移轉，一旦啟動這項措施，用戶您開始進行容錯轉移動作，將資料庫移轉至備援資料中心的資料庫，並停止主要資料庫與備援資料庫之間的資料複製動作。
這種方法使得容錯移轉變得相當簡單，應用程式只需要判斷是否啟用容錯移轉的旗標 ( flag )，再來決定要進行容錯移轉還是等待目前資料庫復原。這兩種選擇會依據應用程式需求而有所不同。若您的應用程式比較注重不停機的高可用性 ( higher availability ) 並能容忍漏失過去一個小時已經儲存於主要資料庫內的資料，當為微軟啟用允許容錯轉移後，用戶應盡速啟用容錯移轉。倘若您的應用程式比較注重資料的完整性，已經儲的資料遺失是非常敏感 ( sensitive ) 的，雖然微軟已經允許標準異地備援用戶開始進行容錯轉移，用戶能可能願意繼續等待 Azure SQL Database 恢復正常，以避免資料庫內的資料漏失。然而，若是主要資料庫所在之 Azure 資料中心若是在發生停機後 24 小時之內都沒法復原，則標準異地備援的資料庫都會自動執行容錯移轉動作。在這種最壞狀況下，應用程式將會有 24 小時的停機時間並且會有部分資料遺失。無論是用戶自己啟動容錯移轉或是等待 24 小時讓它自行發生，用戶都需重新配置與設定您的應用程式的資料庫連線，連接到容錯轉移後的備援資料庫。
完成容錯轉移之後，您也會想要確定新的主要資料中心 ( Primary region ) 是否也受到相同的保護，因此在進行容錯移轉的過程中，Azure 會更新它的災難恢復配對資料中心 ( DR pair )，這將允許您從新的主要資料中心 ( Primary region ) 來啟動新的地理資料複製來保護它自己。由於建立新的備援區域需要花費一些時間 ( 取決於資料庫資料量大小 )，您必須承擔在建立新的備援區域的這段期間，Azure SQL Database 暫時無高可用性備援能力，並且接受在沒有保護狀態下執行應用程式的風險。最妥當的辦法就是等待容錯移轉資料庫已經有完整備援資料中心保護之後，再啟動應用程式。
建立完備原資料中心後，新的災害復原 ( DR ) 的配置如下圖所示 :
圖二 : 在容錯移轉更新完新的災難備援配對資中心之後，應用程式可以建立一個新的備援資料庫並開始資料複製動作
由於資料庫的容錯移轉與資料是相互關聯並且是一個具破壞性的回復方式，因此容錯移轉的整個流程應該要定期經過測試來確保應用程式能夠應付災難發生時的突發狀況。這個測試的過程叫做災壞復原演練 ( Disaster Recovery Drills )。許多國際資訊安全相關認證也要求應用程式備妥與進行災壞復原演練。雖然平時在 Azure SQL Database 正常運行的情況下，在備援資料中心內離線 ( offline ) 的備援資料庫無法真的進行容錯移轉，但是在災害復原演練時，用戶還是可以透過停止主資料庫 ( primary database ) 的地理複寫的方式，讓被援資料中心的資料庫可以被用戶啟用。來測試整體的災害復原流程。
在經過容錯移轉之後，備援資料庫將可以完全地被存取，就像主資料庫般的讓應用程式使用。在演練的過程中，資料有可能會遺失而且在這段時間主要資料中心內的資料庫並沒有受到保護，因此我們不建議客戶在實際生產用的資料庫上進行災害復原演練。我們建議您在主資料庫所在的資料中心內建立一個資料庫副本，並且使用這個副本和它的輔助區域來測試容錯轉移流程演練。
標準異地備援提供了在主動異地備援上啟用的REST API子集。要管理標準異地備援，您可以使用這個API並且提供PowerShell指令或是使用Azure管理網站。由於這項功能還在預覽階段，因此您需要先登入到Azure SQL Database的新服務層。啟用標準異地備援最簡單的方式就是使用Azure管理網站中的"異地備援"選項。
圖三 : 使用 Azure 管理網站建立和監控離線地理輔助區的狀態
要注意的是，您可以在任何時候選擇取消地理複製。有兩種方式可以達到此效果，您可以在主資料庫上終止地理複製或是直接刪除備援的次要資料庫。
第一種方式是當您複製到錯誤的資料庫時，可以有效的終止這個動作。若您在備援資料庫建立好之前就取消這項動作，您將不會被收取任何費用，但若在備援資料庫已經建立好之後才取消，則您需要按照您使用的額度來支付費用。使用第二種方式，將會自動停止地理資料複製並且刪除備援資料庫，並且從停止的那一刻開始停止收費。
標準異地備援針對擁有適度資料更新速率的應用程式，提供了一個強大的災難恢復解決方法，雖然它不如主動異地備援來的靈活，但是我們認為它還是符合大多數應用程式的需求。請告知我們您的想法，我們會認真聽取您在新的 Azure SQL Database 服務層中使用地理複製地回覆意見，您能夠在以下文章中得到更多資訊。
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 9 月 13 日所發表的文章 http://azure.microsoft.com/blog/2014/09/13/azure-sql-database-geo-restore/
本篇文章將會繼續介紹有關於 Azure SQL Database 中針對業務連續性 ( Business Continuity ) 以及災害復原 (
BCDR, Business Continuity and Disaster Recovery ) 相關功能中的異地還原 (Geo-Restore) 功能。在先前介紹標準異地備援 ( Standard Geo-replication ) 文章中，我討論了 Azure SQL Database 不同服務層 ( Service Tier ) 中對於處理災難復原的各項選擇，以下的表格可以讓我們快速的複習。
RTO ( Recovery Time Objective ) : 系統要在多少時間內回復正常
RPO ( Recovery Point Objective ) : 可忍受的資料遺失的時間長度
Basic 版
Standard 版
Premium 版
還原至過去 7 天內的某時間點
還原過去 14 天內的某時間點
還原過去 35 天內的某時間點
異地還原（Geo-restore）是一種利用地理容錯備份 ( geo-redundant backup ) 來還原並建立新資料庫的一種技術，此功能適用於任何 Azure SQL Database 所在之資料中心。由於它使用了一個地理容錯備份來還原資料庫，因此即使資料庫因為不明原因停擺，還是能夠在異地進行還原的動作。異地還原功能內建在所有的 Azure SQL Database 服務層中 ( Basic、Standard、Premium )，此功能無須額外設定即會自動的運作，並且不會增加任何額外的花費。
Azure SQL Database 異地還原使用了與時間點還原 ( point in time restore ) 相同的技術，只有一個主要的差別，那就是它使用了 Azure Storage BLOB 讀取權限異地備援儲存體 ( RA-GRS ) 的特性，讓資料庫的備份資料儲存於 BLOB 內，並透過 Azure Storage BLOB 異地備援功能備份到另一配對之資料中心，再將時間點最近的異地資料庫副本來還原資料庫。
每一個主要的 Azure SQL Database 資料庫皆會維護一個備份鏈 (backup chain) ，所謂備份鍊包含了每週一次完整備份 ( full backups )、每天一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )，透過這個備份鏈，所有最新的完整備份和差異備份皆會儲存到 Azure Storage BLOB ( RA-GRS ) 儲存體中。由於這些 BLOB 具備地理複製 ( geo-replicated ) 能力，因此即使在資料庫的主要區域 ( Primary region ) 中發生大規模的故障，備份在異地資料中心的資料不會受到影響。
下圖呈現了這個過程 :
圖一 : 每週和每日的備份儲存在儲存體容器 ( storage container )中，透過 Azure Storage BLOB RA-GRS 地理複寫功能，將資料庫自動備份副本複寫到配對資料中心 Azure Storage BLOB 內。
如果發生大規模的故障事件造成 Azure SQL Database 資料庫所在之資料中心停擺，用戶就可以利用異地還原的功能來將資料庫還原到配對區域的資料中心內的 Azure SQL Database，以便盡速繼續提供服務，但由於 Azure Storage BLOB 儲存體內儲存的是 Azure SQL Database 每日差異備份的內容，因此 RPO ( Recovery Point Objective 可忍受的資料遺失的時間長度 ) 最長可能會達 24 小時。
圖二: 利用 Azure SQL Database 每日備份在異地進行還原資料庫動作
異地還原能夠從 Azure 管理網站上使用。在 Azure SQL Database 列表中選取要備援的伺服器，並且選擇"備份"的選項。
在備份的選項中，提供了該伺服器中所有可以使用的備份清單，其中也包含了上次備份的時間以及備份的服務層版本。
當您選擇了一個備份進行還原，您需要為新建立的還原資料庫提供一個名稱，並且指定目標伺服器，一旦按下確認之後，還原動作將會把還原資料庫放置到指定的伺服器上。
圖三 : 在 SQL資 料庫中選取 "伺服器"選項
圖四 : 選擇您要還原的資料庫，並且選取"備份"選項
圖五 : 在異地備份列表上選擇要還原的資料庫
圖六 : 設定還原資料庫的名稱以及目標伺服器
圖七 : SQL資料庫列表會顯示出資料庫正在還原
如同 Microsoft Azure 其他各項管理功能，用戶同樣地也可以透過 REST API 或 PowerShell 來進行上述的還原步驟。
透過 Azure 管理入口網站來進行還原資料庫的動作，較適合特別且小量的資料庫還原。而使用 REST API 或 Powershell 則適用於多個資料庫還原或是自訂管理腳本 ( Script ) 和應用程式。您可以參考 Azure SQL Database REST API 和 Azure SQL Database Recovery PowerShell API。
若啟動了一個錯誤的還原操作，您不需要等待還原的動作結束才進行取消，可以透過將還原資料庫刪除的方式，來取消此操作取消，這樣就可以避免有任何費用的產生。
影響恢復時間 ( recovery time ) 的因素
恢復時間會受到以下因素影響 :
若有一個區域資料中心長期處在停機的狀態下時，則其他區域就有可能產生大量的異地還原要求 ( geo-restore requests )。此時系統會適時限定還原資源的分配，以確保原本在該區域的工作附載 ( workloads ) 不會受到影響。因此若有大量的請求湧入，勢必會增加該區域恢復資料庫的時間。
雖然異地還原適用於所有 Azure SQL Database 服務層 ( Basic、Standard、Premium)，但這只是最基本的資料庫災害復原解決方式( Disaster Recovery solution )，因此 PRO 和 RTO 會比其他進階的災害復原解決方式 ；例如 : 標準異地備援 ( Standard Geo-Replication ), 主動異地備援 ( Active Geo-Replication ) 花費的時間來的長。
一個 Azure SQL Database Basic 層級擁有最大的 2GB 異地還原，異地還原提供了一個合理的災害復原解決方式 ( RTO 為24小時 )。而對於 Standard 和 Premium 層級的資料庫而言，若是想要讓恢復時間縮短或是減少資料量的遺失，您可以考慮使用標準異地備援 ( Standard Geo-Replication ), 主動異地備援 ( Active Geo-Replication ) 。這兩個異地備援機制提供了較短的 PRO 和 RTO。
透過災害復原演練，可以展示出一個生產用的資料庫在災難停機的狀態下受到保護的效果。由於異地還原可以在任何時間點進行，因此可以透過定期的災害復原演練來證實這些還原功能是可以正常運作的。
透過異地還原 ( Geo-Restore )、標準異地備援 ( Standard Geo-Replication )、主動異地備援 ( Active Geo-Replication ) 的結合，提供了多種選擇來符合您業務需求的商業連續性解決方案 ( business continuity solution )。
以下表格總結了各個異地備援方案的不同之處 :
(Geo-Restore)
線上應用程式更新 ( upgrade )
線上應用程式移轉 ( relocation )
我們鼓勵您可以藉由嘗試不同方案的異地備援來找到適合自己的業務連續性與災害復原策略。與往常一樣，我們會認真的聽取各方意見，所以請您透過網站來告訴我們任何可以改善的地方。
您可以閱讀更多關於 Azure SQL Database 備份與還原的文章。
感謝北科大劉建昌同學翻譯微軟公司 Azure SQL Database 團隊主管 Tony Petrossian 於 2014 年 10 月 1 日所發表的文章 http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/
本篇文章，將說明 Azure SQL Database 的時間點還原 ( Point in Time Restore ) 功能，這項功能在 Azure SQL Database 的 Basic、Standard、Premium 版皆有提供。在先前的文章中，Azure SQL Database 團隊已經介紹了 Azure SQL Database 多項新功能，其中也包含了時間點還原，您可以參考下列圖表。在這份圖表我們可以看到，時間點還原功能是使用最近的資料備份 ( backup ) 來還原受損或是遭到刪除的資料庫。
Azure SQL Database 服務中的所有資料庫，皆會受到自動備份系統 ( automated backup system ) 保護。備份的保留期限會隨著訂閱的 Azure SQL Database 層級而有所不同，Premium 版為 35 天、Standard 版為 14 天、Basic 版為 7 天。
時間點還原為一個自助式服務 ( self-service )，允許客戶利用在保留期間所做的的備份來還原資料庫。在使用時間點還原功能時，會重新建立一個新的資料庫。
Azure SQL Database 資料庫備份採取自動備份，您不需要做設定而且也不會額外針對備份來作收費，您只需要在使用時間點還原功能時負擔額外的費用。還原時所建立的新資料庫，其收費標準跟平常的資料庫收費標準一樣。
總而言之，自動備份系統和時間點還原提供了零成本和零管理的方式來保護您的資料，無論任何原因損毀了資料庫，您都可以在保留期間內任一時間點中回復。
所有的 Azure SQL Database 資料庫的 Basic、Standard、Premium 版都提供了自動備份的功能。Azure SQL Database 會每週做一次完整備份 ( full backups )，每天做一次差異備份 ( differential backup ) 以及每五分鐘進行交易記錄備份 ( log backups )。當資料庫被建立完成後即會開始第一次完整備份，這通常要花費 30 分鐘甚至更久的時間來完成備份。若該資料庫生來規模就很大 ( born big ) (例如 : 建立的資料庫為資料庫副本或是從大型資料庫還原所產生的資料庫 )，備份所需的時間會花費更久。在第一次備份完成之後，所有後續的備份會自動的由系統做安排，並且 "默默" 地在後端進行管理。
完整備份 ( full backups ) 和差異備份 ( differential backups ) 的確切執行之時間點，是由系統依據目前以系統負載量來做決定。而備份的檔案儲存在與目前資料庫相同的資料中心內。
當您還原一個資料庫時，還原所需的備份檔案將從本地備援處 ( local redundancy ) 來獲取。而每週和每日的最新備份也會複製到 Microsoft Azure 地理備援的配對資料中心 ( paired region ) 以便進行跨資料中心之災難回復。關於異地還原 ( Geo Restore ) 的敘述，在 Azure SQL Database 團隊之前發表的文章中有更詳細的敘述。
進入 Azure 管理入口網站，即可透過簡單的操作將各版本之 Azure SQL Database ( Basic、Standard、Premium ) 資料庫還原到任何的時間點 ( 但必需在備份的保留期限內 )。
您可以選擇在資料庫列表中選取需要還原的資料庫，或是進入該資料庫的儀表板內，並且點擊"還原"選項。
您將會被提示要輸入一個新的資料庫名稱，並且利用滑動元件來選取想要還原的時間點 ( 必需在保留期限內 )，同時也可以手動輸入最接近的時間點。完成之後按下確認鍵，資料庫便會開始還原到您所設定的時間點。
還原資料庫所需的時間由很多因素決定，包含 : 資料庫大小、選取時間點遠近、要還原到選取時間點資料庫需要重新架構的狀態數量等，通常一個龐大的資料庫，需要數個小時來還原。
還原的資料庫將會被建立在與原始資料庫相同的伺服器上，也因此我們需要重新賦予資料庫新的名稱。而還原資料庫的服務層級則是與還原時間點時資料庫設定的服務層級相同。
您需要確認您的資料庫有足夠的資料庫傳輸單位額度 ( DTU )，同時也要注意的是，還原時所建立的新資料庫，其服務層級可能會與目前資料庫的狀態不同。
一旦完成了還原動作，還原的資料庫收費標準與一般的資料庫是相同的。
您可以將還原資料庫來替換原本的資料庫，或是利用還原資料庫作為資料檢索，再去更新原始的資料庫。
若您還原資料庫的目的是用來取代現有的資料庫，您應該要驗證服務層級與效能層級是否合適，並且在需要時進行擴充。透過更改原始資料庫名稱，再將還原資料庫的名稱利用 T-SQL 指令 ALTER DATABASE 將名稱更改為原本資料庫的名稱，這樣就可以完全取代原本的資料庫了。
若您計畫從備援資料庫內讀取資料，您將需要分別編寫和執行您所需要回復資料相關之 Script。
雖然還原資料庫需要花費相當長的時間，但是在還原的過程時，還原資料庫就會顯示在資料庫列表上。您可以在還原的過程中刪除還原資料庫，此時將會取消還原的動作，您將不需要付出任何費用。
您能夠將在其保留期限內不小心遭到刪除的資料庫還原到被刪除的時間點，或更早的時間點。
您可以使用 Azure 管理入口網站來還原被刪除的資料庫，首先需要在 Azure SQL Database 的資料庫列表中，選取"已刪除的資料庫"選項，將可以看到還在保留期限內遭到刪除的資料庫列表。
注意 : 若您重複使用太多次相同的資料庫名稱，則需要更加注意刪除的時間，這樣才不會還原到錯誤的資料庫。
就如同先前還原步驟一樣，您需要為還原資料庫新增一個名稱，而且您還原的資料庫也只能夠還原到與原始資料庫相同的伺服器上。比較特別的是，在這種情況下的還原步驟，只能夠選取固定的時間點作還原。還有一點要注意的是，當您刪除伺服器(Server)之後，您將無法復原先前存放在該伺服器的所有資料庫。
時間點還原可以將資料損毀或是被刪除的資料庫重新復原。時間點還原並非使用先前 Azure SQL Database Web/Business 版資料庫運用複製為技術基礎，所實作出的匯出 ( Export ) / 自動匯出 ( automated export ) 方式 ( 此方式較為昂貴 ) 來回復資料庫。單單這一改進就證明了新版 Azure SQL Database 的優勢。
注意 : 雖然在保存期限內，利用備份方式回復資料庫是相對便宜及快速的，而使用複製/匯出/匯入方式仍適用於更長期資料庫備份策略 ( long term archival )。
除了透過 Azure 管理入口網站來還原資料庫之外，您也可以使用 PowerShell ( Start-AzureSqlDatabaseRestore ) 和 SQL Database management API 來還原資料庫。
自動備份與時間點還原(自助式服務)功能保護您的資料庫，讓其能夠從資料損毀以及刪除的狀態下回復，這種零成本和零管理的方法，不管是在哪一種服務層Basic、Standard、Premium)的資料庫都有提供。備份和還原功能在短期回復的需求下，性能較優於使用複製/匯入/匯出的方式，因此就短期資料庫回復而言，我們鼓勵���使用這種方式來做為您的商業連續性對策，而僅在需要長期歸檔或數據轉移時才使用匯出/匯入的方式。
最近在 Microsoft Azure 的首頁上多了一個「主機庫」（Gallery）的頁面，這一頁蒐集了 Azure 各種服務所提供的開始選項，以虛擬機器來說，就是展示已經在 Azure 上獲得官方支援的各種作業系統映像檔：
而在 Web 應用程式的部份，也陳列了由 Azure 團隊驗證過可以順利並直接安裝在 Azure 上的各種開源的架站套件：
只要挑選一個架站套件就可以立即開始架設網站，比方說很多人喜愛的 WordPress 套件：
只要按下 Create Web App 的按鈕就可以開始拿 WordPress 在 Azure 網站服務上架設網站囉！
如果您發現在 Gallery 中找不到您喜愛的架站套件，歡迎您到這裡來反應，我們會盡快考慮移植上 Microsoft Azure。
感謝北科大劉建昌同學翻譯微軟公司 Azure Media Services 團隊主管 Cenk Dingiloglu 於 2014 年 9 月 18 日所發表的文章 http://azure.microsoft.com/blog/2014/09/18/azure-media-services-rtmp-support-and-live-encoders/
Microsoft Azure Media Services 直播串流服務功能日前已經進入技術預覽階段，公開接受用戶測試。而在直播串流服務中所用到的RTMP 協定是 Microsoft Azure Media Services 支援的內嵌 ( ingest protocol ) 協定之一，也是目前市場上常用的協定，用來獲取與傳送多媒體資訊。
Microsoft Azure Media Services 提供了使用 RTMP 協定來內嵌串流資訊並且使用動態封裝 (Dynamic Packaging) 來傳送不同的媒體串流格式 (例如 : MPEG-DASH、Microsoft Smooth Streaming、Apple HLS、Adobe HDS )。RTMP 協定目前被廣泛應用在影音輸入與傳輸，支援 RTMP 協定讓 Microsoft Azure Media Services 直播串流服務能夠將獲取的影片；多重輸出串流至不同媒體格式的裝置與端點上，並且能夠保持與傳統撥放器的相容性。
關於在 Azure Media Service 上設定一個直播通道 ( Live Channel ) 和串流端點的資訊，請參考 Microsoft Azure 中文部落格 - 如何使用 Microsoft Azure Media Services 進行現場直播 ( Live Streaming )
本篇文章的重點將放在介紹 Azure Media Service 的 RTMP 內嵌功能，以及如何透過 Wirecast、Flash Media Live Encoder ( FMLE )、FFmpeg 等編碼器，利用 RTMP 協定將多種畫質之多重位元資訊 ( multi-bitrate ) 即時送進 Azure Media Service 的通道中 ( Channel )。
即時串流的架構最主要由三個主要的元件所組成：通道/節目 ( Channel/Program )、串流端點與串流單位 ( Streaming Endpoints )、儲存體 ( Storage )
1. 通道/節目( Channel/Program ) :
2. 串流端點 ( Streaming Endpoint ) 與串流單位 ( Streaming Units ):
3. 儲存體 ( Storage )
Azure Media Services Channel 支援 RTMP 協定將串流推向通道中，它可以支援單一 ( single bitrate ) 和多重位元輸入 ( multi-bitrates )，不過我們強烈建議使用多重位元輸入 ( multi-bitrates ) ，這樣的好處是可以讓不同單位可以使用自己最適合的串流位元。在未來的 Azure Media Services 中，將會提供即時轉碼服務，這個服務能夠將單一的位元 ( single bitrate ) 輸入轉換成多重位元輸出 ( multi-bitrates )。
要使用 RTMP 嵌入協定 ( ingest )，需要符合下列要求 :
在這篇文章中，將會使用三種不同的視訊輸出品質，並且內嵌 ( ingest ) 到 Azure Media Service Channel 之中。您可以使用更多的視訊輸出品質，但是要記住的是，您的輸出品質將被您的電腦編碼能力還有網路頻寬所限制，若您的網路頻寬較小，您可能會需要調整所使用的輸出品質數量，並且使用較低的編碼位元率 (bitrate)。當您嘗試輸出較多種視訊品質時，需要注意所需的網路頻寬是所有視訊品質的位元率總合。
注意 : 當您重新設定編碼器或是重新建立編碼器與通道之間的連線時，都要對通道進行 "Reset" 的動作。
Wirecast 是一種支援 RTMP 協定的商用編碼器軟體。它可以即時編碼直播時所獲取的即時串流。您可以到 Telestream 網站下載 Wirecast 試用版並且得到相關的資訊，目前 Wirecast 最新版本為版本 5，並且能夠用來測試 Azure Media Service。
輸入設定
輸出設定
此時會出現輸出設定的對話框
注意 :
1. 當您在建立自己的預設編碼時，您必須保持 “Frames per second” 和 “Key frame every” 這兩個值在不同的輸出品質之間是相同的。
2. 不同輸出品質，必須使用相同的音訊編碼設定並且確定有設置 "Keyframe Aligned"，否則串流將無法運作或是無法內嵌置通道中。
再次提醒，在建立新的預設編碼時，"Frames per second" 和 "Key frame every" 這兩個值在不同的輸出品質也要是一樣的。除此之外，也要確認有設置 "Keyframe Aligned" 並且為每個 Stream 命名一個唯一的名稱。
開始編碼並且將串流資料內嵌到通道中
預覽串流
您可以透過Azure管理網站來預覽甚至是發布您的串流。
(關於預覽與發布串流的詳細資訊，請參考Microsoft Azure中文部落格如何使用 Microsoft Azure Media Services 進行現場直播 (Live Streaming))
做為替代方案，您也可以使用http://amsplayer.azurewebsites.net/來選擇不同的播放器來預覽您的串流視訊。
FMLE 為 Adobe 公司發行的一個免費軟體。您可以至 http://www.adobe.com/products/flash-media-encoder.html 下載FMLE以及了解更多相關訊息。
在預設的情況下，FMLE 支援 MP3 格式的音訊輸出。目前 Azure Media Service 並不提供即時轉碼服務，並且要求必須使用進階音訊編碼 ( AAC ) 以動態封裝串流到多種格式中 ( MPEG-DASH、Smooth Streaming、HLS )。因此，為了要在 Azure Media Service 上使用 Adobe FMLE，您會需使用額外的 ACC 插件 ( plugin ) 。在本篇文章中，我們將會使用一個由 Main Concept 所提供的 FMLE ACC 插件。(您可以從 http://www.mainconcept.com/eu/products/plug-ins/plug-ins-for-adobe/aac-encoder-fmle.html 下載與安裝此一 ACC 插件)
設定 FMLE
您需要做的第一件事情是設定讓 FMLE 使用 Network Time Protocol (NTP) 做為 RTMP 協定的時間標籤，請依照下列步驟 :
1. 關閉您的編碼器
2. 使用文字編輯器打開 FMLE 的組態檔 (config.xml)。
3. 將 streamsynchronization/enable 設定true，如以下範例 :
<streamsynchronization>
<!– “true” to enable this feature, “false” to disable.
<enable>true</enable>
4. 儲存檔案，並且再次打開您的編碼器。
若您要自己建立一個預設編碼，請參考本文 "通道支援 RTMP 協定" 章節。
在本篇範例中，將使用
"Multi Bitrate – 3 streams (1500) Kbps – H.264"
此選項將採用H.264標準的多位元率編碼，並且輸出三種不同的輸出串流。
( 注意 : 在預設的狀況下 ACC 和 HE-AAC 不能使用，因為 FMLE 只能夠輸出 MP3 格式的音訊檔，因此您需要通過外部的插件來讓 FMLE 使用 AAC 編碼 )
下圖為上述完成的設定
注意 : 您也可以使用 FMLE 的指令模式完成上述的操作。
詳細資料請參考“Start Flash Media Live Encoder in command-line mode”
您可以透過 Azure 管理網站來預覽甚至是發布您的串流。關於預覽與發布串流的詳細資訊，請參考 Microsoft Azure中文部落格如何使用 Microsoft Azure Media Services 進行現場直播 ( Live Streaming )
做為替代方案，您也可以使用 http://amsplayer.azurewebsites.net/ 來選擇不同的播放器來預覽您的串流視訊。
FFmpeg 是知名的開放原始碼計畫，可以支援多種格式的音訊和視訊輸出。RTMP 也是 FFmpeg 上所支援的一項協定。您可以在FFmpeg 的官網下載與了解更多相關資訊。在這篇文章中，將不會特別介紹和說明 FFmpeg 的指令和其用處，而是使用先前已經撰寫好的指令來將本地端的檔案進行串流，並且模擬一個即時串流。您可以使用 FFmpeg 來截取來自多種不同設備 (包含攝影機、桌面截取等設備) 的輸入的資訊。您可以在 FFmpeg 的官網下載與了解更多相關資訊。
範例指令
以下為 FFmpeg 的範例指令
C:\tools\ffmpeg\bin\ffmpeg.exe -v verbose -i MysampleVideo.mp4 -strict -2 -c:a aac -b:a 128k -ar 44100 -r 30 -g 60 -keyint_min 60 -b:v 400000 -c:v libx264 -preset medium -bufsize 400k -maxrate 400k -pix_fmt yuv420p -f flv rtmp://channel001-streamingtest.channel.media.windows.net:1935/live/a9bcd589da4b424099364f7ad5bd4940/mystream1
C:\tools\ffmpeg\bin\ffmpeg.exe -threads 15 -re -i MysampleVideo.mp4 -strict experimental -acodec aac -ab 128k -ac 2 -ar 44100 -vcodec libx264 -pix_fmt yuv420p -s svga -b:v 500k -minrate 500k -maxrate 500k -bufsize 500k -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -f flv rtmp://channel001-streamingtest.channel.media.windows.net:1935/live/a9bcd589da4b424099364f7ad5bd4940/Streams_500 -strict experimental -acodec aac -ab 128k -ac 2 -ar 44100 -vcodec libx264 -pix_fmt yuv420p -s vga -b:v 300k -minrate 300k -maxrate 300k -bufsize 300k -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -f flv rtmp://channel001-streamingtest.channel.media.windows.net:1935/live/a9bcd589da4b424099364f7ad5bd4940/Streams_300 -strict experimental -acodec aac -ab 128k -ac 2 -ar 44100 -vcodec libx264 -pix_fmt yuv420p -s qvga -b:v 150k -minrate 150k -maxrate 150k -bufsize 150k -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -f flv rtmp://channel001-streamingtest.channel.media.windows.net:1935/live/a9bcd589da4b424099364f7ad5bd4940/Streams_150
在輸出多種位元率的指令碼中，建立了三種不同的視訊輸出品質 ( 500Kbps, 300Kbps, 150Kbps )，主要畫面間隔為兩秒。並且在將串流輸出到 Azure Media Service 通道 ( Channel ) 中。請參考 Microsoft Azure中文部落格如何使用 Microsoft Azure Media Services 進行現場直播 ( Live Streaming )，裡面有關於通道內嵌URL的詳細介紹。
C:\tools\ffmpeg\bin\ffmpeg.exe -list_devices true -f dshow -i dummy
得知麥克風與攝影設備的名稱，以此範例，攝影設備名稱為 Integrated Camera 而麥克風設備名稱為 Microphone (High Definition Audio Device)，以下是將電腦 WebCam 透過 ffmpeg 編碼為 H.264 送往 Azure Media Services Live Streaming Channel 的範例:
C:\tools\ffmpeg\bin\ffmpeg.exe -v verbose -f dshow -i video="Integrated Camera":audio="Microphone (High Definition Audio Device)" -strict -2 -c:a aac -b:a 128k -ar 44100 -r 30 -g 60 -keyint_min 60 -b:v 400000 -c:v libx264 -preset medium -bufsize 400k -maxrate 400k -pix_fmt yuv420p -s 640x360 -f flv rtmp://channel001-streamingtest.channel.media.windows.net:1935/live/a9bcd589da4b424099364f7ad5bd4940/mystream1
您可以透過 Azure 管理網站來預覽甚至是發布您的串流。關於預覽與發布串流的詳細資訊，請參考Microsoft Azure中文部落格如何使用 Microsoft Azure Media Services 進行現場直播 ( Live Streaming )
進階設定
在預設的情況下，Azure Media Service 通道被設定為每兩秒內嵌主畫面資料，並且使用 HLS 輸出 3 對 1 的對映設定 ( 3 to 1 mapping )，這代表著若您每兩秒內嵌一次主畫面資料，則您的 HLS 輸出片段則為六秒 ( 3 * 2 = 6 second )。
若您想要調整這個內嵌的時間間隔，您必須使用 SDK。因為這種進階設定無法透過 Azure 入口網站做設定。您可以透過 Creating a Live Streaming Application with the Media Services SDK for .NET 來了解更多使用SDK來進行進階設定的資訊
關於設定的參數，請參閱 ：
• ChannelInput/KeyFrameInterval
• ChannelOutput/Hls/FragmentsPerSegment
本篇文章介紹了如何在 Azure Media Service 使用支援 RTMP 協定的多種編碼器，以及介紹了詳細的設定細節 。
除了上述的功能之外，您還可以使用 Azure Media Service 完成更多的功能，更多的資訊您可以參考官網 “Azure Media Services”，也可以透過 SDK 來完成建立即時串流 “Working with Azure Media Services Live Streaming” 。
希望您透過上述的文章可以了解如何在 Azure Media Service 上使用 RTMP 協定的編碼器，若是有任何的問題，可以透過官網讓我們知道。
MySQL 是相當常用之資料庫伺服器，而微軟雲端服務 Microsoft Azure 上 Azure SQL Database 是一個功能強大且經濟實惠的選擇，透過本篇文章，使用 SQL Server Migration Assistant ( 以下簡稱 : SSMA ) 利用幾個簡單的步驟，可將您的 MySQL 資料庫移轉到 Microsoft SQL Server 或是 Azure SQL Database 上。
SSMA 支援多種架構的資料庫 (Sybase、Oracle、MySQL) 快速移轉到 Azure SQL Database 或 Microsoft SQL Server。它將移轉資料庫的主要步驟；例如 : 結構 (Schema) 轉換、SQL 陳述式轉換、資料表格移轉等加以自動化，來減少從不同架構的資料庫移轉至 Azure SQL Database 或 Microsoft SQL Server 的時間和風險。SSMA 目前提供以下多種版本:
Microsoft SQL Server Migration Assistant v6.0 for Oracle
Microsoft SQL Server Migration Assistant v6.0 for MySQL
Microsoft SQL Server Migration Assistant v6.0 for Sybase
Microsoft SQL Server Migration Assistant v6.0 for Access
關於安裝步驟，詳情請參考 : SQL Server Migration Assistant Team's Blog
1. 下載並且安裝 Microsoft SQL Server Migration Assistant for MySQL
2. 開啟 Microsoft SQL Server Migration Assistant for MySQL
接著點選 File 來新增一個新的資料庫物件(object)。
在新增物件的對話方塊中，會要求輸入物件名稱以及要將 MySQL 資料庫移轉到哪個版本的 Microsoft SQL Server 或是 Azure SQL Database ( 舊名 SQL Azure )。本範例中我們選擇將 MySQL 資料庫移轉到 Microsoft SQL Server 2008 Express 版。
選取 "OK"，則新的資料庫物件就建立好了。
注意 : 若是您目前的 SQL Server 版本是舊版本 (例如 : SQL Server 2008)，則您資料庫物件轉移選項不能夠高於此版本。
3. 建立 MySQL 資料庫連線
選取左上角的 "Connect to MySql"
輸入 MySQL 的伺服器名稱、連結的通訊端口、使用者名稱與密碼
輸入完畢之後，點選 "Connect" 按鈕，接著如下圖所示。在左上邊的 MySQL Metadata Explorer 會顯示出我們想要轉移的 MySQL 資料庫 (world)，而在最下方輸出列中會顯示 SQL Server Migration Assistant 已經成功的連接到 MySQL。
上圖右方則是可以讓我們設定對映的 Type、Schema 等移轉的選項。
4. 連接 Microsoft SQL Server。
選取左上角"Connect to SQL Server"
接著輸入 SQL Server 的伺服器名稱、目標資料庫名稱以及使用者帳密。
輸入完畢之後，會看到以下的警告訊息。
會出現以下原因為 SQL Server 2008 Express R2 不提供SQL Agent，但是這並不影響移轉的結果，這邊選擇繼續。
若您輸入的資料庫在 SQL Server 中不存在的話，會有提示告訴您要建立一個。
如同步驟三一樣，在最下方工具列上，可以看到 SQL Server Migration Assistant 已經成功的連到了目標 SQL Server
5. 轉換結構描述(Convert Schema)
目前 SQL Server Migration Assistant 已經連接上了 MySQL 和 SQL Server，接著我們要來轉換結構描述，將 MySQL 資料庫中的欄位、欄位類型、主鍵 (primary key)、外鍵 (foreign key) 等結構轉換適用到 SQL Server。
點選要轉換的MySQL資料庫，選取上方工具列的"Convert Schema"。
完成轉換後，我們可以看到 SQL Server 裡面已經有與 MySQL 資料庫中相同的 Schema。
6. 同步 (Synchronize)
上述步驟已經將 MySQL 的表單和 Schema 轉換到 SQL Server 上。下一個步驟，我們要使用 SSMA 將 SQL Server 與資料庫物件做同步。
在SQL Server資料庫中，點擊滑鼠右鍵，選取 "Synchronize with database "
在最下方的輸出列中可以看到同步已經完成了。
7. 將MySQL 的資料轉移到 SQL Server
最後一個步驟就是將 MySQL 資料庫內的所有資料全部轉移到 SQL Server 之中。
選取工具列上的 "Migrate Data"
資料轉移結束之後，可以從資料轉移報告上看到資料移轉的情況
從下圖可以看到資料成功的從 MySQL 資料庫移轉到 SQL Sever上
將 MySQL 資料庫移轉到Azure SQL Database 的步驟其實與上面所述相當接近，只有在建立資料庫物件與建立連線上有些許的差別。
1. 點選 File來新增一個新的資料庫物件 (object)。
與上述有差別的地方就是，在建立物件的對話框中，我們要選取移轉的資料庫為 ”SQL Azure” ( Azure SQL Database 舊名)
當資料庫物件建立完成，並且與 MySQL 資料庫連接 (上述步驟3)，此時我們要來建立與目標 Azure SQL Database 的連結。
2. 首先要先在 Microsoft Azure 上建立一個 Azure SQL Database。
詳細的方式請參閱這裡
3. 建立好了 Azure SQL Database 之後，我們進入 Azure 管理頁面，並且選擇 ”SQL 資料庫”
4. 在這項服務中，可以看到訂閱帳戶中的所有Azure SQL Database。
點選移轉目標的資料庫後，在儀表板的右下角可以看到 Azure SQL Database 的伺服器名稱，這個名稱就是在下個步驟中，要建立SSMA 與 Azure SQL Database 連線時，所要輸入的伺服器名稱。
5. 由於在步驟1已經告知 SSMA 要移轉的目標為Azure SQL Database，也因此在工具列選項也與上述不同。
選取”Connect to SQL Azure”
在這裡需要輸入步驟4的伺服器名稱、伺服器帳號密碼、目標資料庫名稱
建立完成之後，在左手邊的 "SQL Azure Metadata Explorer" 視窗可以看到，SSMA 已經與您的 Azure SQL Database 完成連線。
6. 建立完SSMA與Azure SQL Database 的連線之後，剩餘的動作包括：轉換結構描述、同步、移轉資料等步驟都與上述相同。
下圖顯示資料已經成功的移轉到Azure SQL Database
7. 完成最後一項步驟之後，透過 Microsoft Azure 的管理網站，我們可以直接使用SQL Database Management Portal 來管理資料庫，在此之前我們需要先取得存取資料庫權限。
進入到Azure SQL Database 的管理頁面，在最下方工具列選取管理。
此時會跳出對話框，詢問您是否要將您目前的 IP 位址加至防火牆規則中，選取"是"，這樣 Azure 就會自動將您的 IP 加至規則中，如此才能夠進入 Azure SQL Database 的管理頁面。
您也可以透過伺服器管理頁面，將您所在的 IP 位址加至允許存取伺服器的 IP 範圍中
8. 取得管理權限之後，就可以使用SQL Database Management Portal 進入到資料庫內部進行管理。
輸入伺服器使用者名稱與密碼 (先前在新增步驟時所建立的)
透過 Azure SQL Database 的管理介面可以看到，MySQL 資料庫的 Schema 和資料已經成功的移轉到Azure SQL Database上。
感謝北科大劉建昌同學翻譯 微軟公司 Azure Media Services 團隊主管 Jason Suess 於 2014 年 9 月 10 日所發表的文章 http://azure.microsoft.com/blog/2014/09/10/getting-started-with-live-streaming-using-the-azure-management-portal/
不久之前，微軟公司宣布了 Microsoft Azure Media Services 即時直播服務 ( Live ) 開始進入技術預覽階段，公開接受用戶測試。而這些即時直播服務其實早已被 NBC 運動頻道用於多項重大運動賽事直播，包括英超聯賽、NHL、週日橄欖球之夜 ( Sunday Night Football ) 以及 2014 年索契冬季奧運會。在最近剛結束的 2014 世界盃足球賽期間，Azure Media Services 即時媒體服務同樣的也被10 家世界性的電視傳播公司用來轉播比賽。也因此，我們對於這項服務的穩定性、可擴充性以及性能都深具信心，也很高興可以讓所有使用者都可嘗試提供即時直播服務給他們的用戶。
自本周起 Azure Media Services 團隊將撰寫多篇文章，內容涵蓋了 Microsoft Azure 即時串流服務的功能以及如何使用它們。首先，我們會介紹一些基本的即時串流所需要的一些要件，並且將其應用到一個特定的場景 (網路直播桌面)。而我們只需要透過 Azure 的管理入口網站，無需任何的程式碼即可達到所需要的設定。但是在未來的幾天，將會有另外一篇文章說明如何使用 Microsoft Azure SDK 以程式控制的方式來達到相同的設定。
以下將開始介紹在進行即時串流時所需要用到的組成，並且在文章的最後，將這些組件做結合。
如果您還沒有微軟的 Azure 帳戶，您需要先到http://azure.com上建立一個新的Azure帳戶，並且在購買前，會有一段免費期可供試用。
如果您還沒有創建 Azure 媒體服務帳戶，這裡有一些相關文件，說明如何建立一個 Azure 媒體服務帳戶http://azure.microsoft.com/en-us/documentation/articles/media-services-create-account/
在本篇文章中，將使用筆記型電腦上的網路攝影機，如果您要使用其它的攝影機，而您的攝影機有提供數位輸出，可直接透過 USB 將攝影機連接到 PC，並且透過軟體進行編碼。倘若您的攝影機沒有支援數位輸出，那您則需要一個視訊擷取卡 ( video capture card ) 將攝影訊號傳入至 PC。
目前 Azure Media Services 媒體服務支援兩種即時內嵌 ( live ingest ) 協定 :
fragmented MP4/Smooth Streaming 和 RTMP (Real Time Message Protocol)。
目前支援 RTMP 這項協定的編碼器軟體已經變得相當普遍，包括 :
1. 免費的編碼器軟體 ( Flash Media Encoder 和 FFMPEG )
2. 平價之商用編碼器軟體 ( Telestream 的 Wirecast )
3. 生產高價值產品 ( NewTek 的 Tricaster )
4. 專業級的編碼器 ( Cisco, Elemental, Image 等 )
在本文範例中，會使用 Telestream 的 Wirecast 做為示範用的編碼器，如果您沒有此一編碼器軟體，可以從Telestream的網站去下載 Wirecast 試用版，它提供了一段免費試用期。需要注意的是，視訊編碼需要耗用相當大的 CPU 資源，因此當以下範例在做視訊編碼時，會限制只有三個編碼品質等級 ( quality level )，並且產生相對的降低位元速率 (bit rates)，若您所使用的筆記型電腦或是 PC 其 CPU 運算能力較低，您需要去監視 CPU 的使用率，若一直高於 70% 的話，您需要考慮刪除一個品質等級或是降低位元率和降低影片解析度。
要提供視訊直播的服務，您需要連接一個高速的網路，而這個網路需要有相當穩定的傳出速度 ( 至少要為傳送視訊的位元速率的 1.5倍 )。考慮到編碼器輸出的位元速率會有波動，因此在本例中，我們建立了三種品質等級的串流 (400、600、900 Kbps)，合計總位元速率為 1900 Kbps，因此最少需要 2850 Kbps (2.85 Mbps) 的網路傳出速率。
通道 ( Channel ) 是在 Azure 媒體服務中的功能，用來實現即時串流。通道在 Azure 媒體服務範圍內提供編碼器輸出一個內嵌點 ( ingest point )。
在媒體服務中資產 ( Asset ) 如同一個容器 (Container)，用來儲存所有與您的串流有關連的音訊、視訊、中繼資料等。
Azure Media Service Program 媒體服務節目是 Azure 媒體服務的運作實體，其運作的流程為，建立一個通道，並且開始將串流透過通道寫入資產 ( Assest ) 中。
當您想要讓資產 ( Asset )可以開始存取流時，您需要在資產中建立一個定位器。
1. 串流端點 (Streaming Endpoint) 提供了一個URL，從中您可以得到您的即時串流或是 VOD (Video On Demand) 資產，同時，也提供了動態封裝功能以及安全的傳送串流。
2. 串流單位 (Streaming Units) 保證了一定的最大輸出量提供給串流端點，每個串流單位提供了 200 Mbps 的串流流出產量，並且根據使用上的需求，可以增加更多的容量到您的串流端點。
在不久的將來，我們將直接整合 Azure CDN 和 Azure 媒體服務。完成之後，串流端點將可以有一個新的設定。那就是允許直接配置一個 Azure CDN 端點連接至您的串流端點。在尚未完成整合的此時，您可不使用 CDN 直接由串流端點作串流播放的動作，或是聯絡 Azure support 部門，商請微軟公司為您的串流端點設置 Azure CDN。
Azure 媒體服務的串流端點提供了動態封裝的功能，因此可用來針對多種不同用戶端所使用的通訊協定，提供不同的媒體串流格式 ，例如 : iOS 使用到 HTTP 即時資料流版本3格式 ( HLS version 3 ) 。在以下範例中，我們將使用一個遵循 動態與適應性媒體串流標準 (MPEG-DASH) 的 HTML/DASH.js 撥放器來支援多個平台的影片撥放 (電腦瀏覽器、Android、Windows Phone)。
有關更多動態封裝的資訊，可以去 Channel9觀看 Nicks 的影片或是到 MSDN網站 查詢。
現在，讓我們來解釋一下本篇案例將可以達到何種效果。
在以下的步驟中，我們將建立一個網路直播，用來撥放電腦視訊鏡頭所拍攝的事件。在直播串流的專有名詞中，我們可以把這項直播想像成一個”事件”(event)並且擁有一個開始的時間和結束的時間。這個觀念和我們平常在電視上看到的直播節目(線性串流Linear streaming)為一個對比，在之後的介紹文章中，我們也會介紹如何使用Azure媒體服務來達到線性串流。
在要進行直播的事件前，我們需要透過以下的步驟來做事前設定。
注意 : 這些步驟可以在任何時間點進行，而不需要趕在開始直播前做設定。
在第一組設定步驟中，我們將使用Azure管理入口網站配置一些基礎建設，這些基礎建設將要用來接收來自編碼器(encoder)的直播串流還有來自客戶端的撥放設備所傳送的封包(packet)。
1. 點擊連結到http://azure.com，然後在最上方的選單中點選”入口網站”(Portal)，登入您的Azure訂閱帳戶，您將會進入到Azure的管理網站。
2. 在最左側的垂直選單中，選取”媒體服務” (MEDIA SERVICES)，您將可以看到在 Azure 訂閱帳戶中的所有媒體服務。
3. 選取你要在哪個媒體服務中建立這項範例。
在這篇文章中，將使用先前建立好的名為 barttest 的媒體服務。
您可以在媒體服務裡面看到頂端的選單，這裡可以用來建立和控制所有媒體服務的細部設定。
若您已經使用 Azure 媒體服務一段時間的話，您將會注意到，現在新增”通道”這項新功能，在這裡可以管理和控制 Azure 媒體服務的即時通道 ( Live Channel )。
4. 選取最上方選單的”通道”選項，將會列出您在這個媒體服務中所建立的通道清單(如果您有建立的話)
5. 若您還沒有建立任何的通道，則在下方會顯示”您沒有任何通道”，選取”新增通道”，將會打開一個對話寬，在這個對話框中設定您的通道屬性。
6. 在”建立新的即時通道”對話框中，輸入您的通道名稱。
接下來要指定通道所使用的採集內嵌協定 (ingest protocol)。在本範例中，我所使用編碼器為 Wirecast，其輸出嵌入協定為RTMP。
最底下有三個選項 :
A. “立即啟動新通道” : 選取這個選項，之後您就不需要再做額外的動作去啟動這個通道。
B. “加入一個資料流單位” : 這個選項在您的串流端點上沒有任何串流單位時，將會自動預設為選取。選取這個選項，Azure 將會自動提供一個串流單位給您，這樣您就不需要再去花時間做設定。
C. “將影片內嵌限制為我電腦的目前IP位址” : 若選取這個選項的話，它會為您的通道申請一個 IP 存取控制清單 (IP access control list , ACL )，ACL 將會鎖定這個通道只能夠在您的電腦上作輸入的動作。在本範例中我們將此選項取消。
7. 點擊對話框右下角的確認按鈕，則Azure媒體服務就會開始建立一個新的通道，並且將一個新的串流單位加到您預設的串流端點中。
您可以在螢幕的底部看到建立新通道的進度列，新增一個新的通道大概需要花上幾分鐘的時間。
透過上面的事前設定，我們現在擁有了進行媒體服務時所需要的基礎建設。
下一個步驟則是設置 Wirecast，並且在我們的 Azure 服務通道上啟動它。
為了加快設定的步驟，我們使用先前已經建立好的 Wirecast 配置文件，在這裡面已經設定好了即時轉播所需要的設定。但是在本文中將不會介紹這個文件的細節，在未來的幾個禮拜，另外一位作者 Cenk Dingiloglu 將會介紹更多關於編碼器的細節。
1. 下載 Wirecast 配置文件 http://jasonsueblog.blob.core.windows.net/wirecastdocument/WirecastDocument.wcst
2. 打開 Wirecast 和剛剛下載的配置文件。您很可能得到和下面圖示一樣的錯誤，那就是 Wirecast 找不到文件中所描述的媒體裝置。會顯示這項錯誤的原因是因為您並沒有使用與本文中相同的錄影設備。在這裡我們先點擊取消，在下一個步驟中我們將會解決這個問題。
3. 在 Wirecast 的用戶介面中，我們可以新增新的影像來源。
在用戶端的底部有三排來源，點取”+”，並且選擇相機的圖示，此時會顯示目前連接電腦的錄影裝置，選取您要的錄影裝置之後，您就可以在錄影來源上看到目前攝影機的輸出畫面。
4. 選取 Wirecast 的 ”Output” 清單，並且選擇 ”Output Setting”。
您可以在對話框上看到，目前有三種串流編碼的品質等級 (400Kbp、600Kbp、900Kbps)。
400Kbp 品質等級是使用 H.264 視訊編解碼標準中的 Baseline profile 編碼格式(H.264 Baseline profile)，用來支援舊的 Andorid 播放設備，而 600Kbp 和 900Kbps 品質等級則是 Main profile編碼格式，用來提供高品質的視訊水準。
在對話框中唯一缺少的則是目標串流位址(Address)，我們在稍後會填寫上去。
5. 回到Azure管理入口網站並且找到您的通道清單。
在通道清單上選取內嵌 URL (INGEST URL)，並且複製這段URL。
6. 再次回到 Wirecast 並且選取 ”Output Setting” 對話框，將剛才複製的內嵌 URL 貼到 ”Address” 框中，在這裡要確保三種品質等級的串流編碼都有進行此項動作。
7. 點擊”OK”按鈕。
8. 點擊您在步驟三時所建立的錄影來源，並且讓它顯示在使用者介面上 ”Preview” 的位址
9. 接下來，點擊“—>”按鈕，將“Preview”的畫面移動到“Live”上，此時您在畫面上可以看到錄影的輸出
10. 完成以上的步驟，您已經完成了所有 Wirecast 的設定，剩下唯一的步驟就是要將您的串流”推”’到您的 Azure 媒體服務通道上。
點選左上角 ”Stream” 按鈕，若一切順利的話，您將可以看到有一個紅點在按鈕中，讓您知道您目前正在進行直播。
11. 現在您可以檢查串流是否正確地從預覽的發送點傳送到通道中。
回到Azure管理帳戶中，在底部的工具列選取”播放”按鈕。此時會有對話框出現，選擇”播放預覽URL”，這個動作將會打開一個視訊撥放器，並且將其連接到您通道上的預覽URL。
NOTE : 注意，若您有任何理由需要停止編碼器並且重新啟動的話，您首先需要在Azure管理帳戶上選取”重設通道”來重新調整您的通道設定。
現在已經將視訊串流移動到通道之中，現在我們可以透過建立媒體服務資產(Asset)、媒體服務節目(Program)還有媒體服務串流定位器來開始我們的事件(Event)，並且讓觀看者可以透過串流端點來觀看我們的直播。
我們將使用一個快速的方法來達到以上的所有目標。
建立和開啟節目
1. 回到 Azure 管理帳戶，並且進入到通道的設定頁面裡，點擊頁面最下方工具列的”啟動資料流”，一旦完成這項步驟之後，通道列表上的”發行URL”將會被填入，您可以從上方的串流端點上拉進您的串流。
現在，直播串流已經被存入資產中，資產是可以從串流端點中拉出的，並且可以動態的打包目前我們所支援的協定 ( MPEG-DASH,、HLS version 3、 HLS version 4、HDS、Smooth Streaming )，我們將充分利用這項功能讓直播串流可以在桌上電腦、iOS 和Android設備上播放
1. 在 Azure 管理入口網站中，在通道列表的頁面，選取複製”發行URL”。
2. 將"發行URL"將它貼到任何一個文字編輯器上
它看起來像是
“http://<您的帳號名稱>.origin.mediaservices.windows.net/<locator_guid>/<stream_guid>.ism/manifest”
在這段URL上添加 (format=mpd-time-csf)，這將告訴串流端點要把串流打包為 MPEG-DASH。若增加的是 (format=m3u8-aapl-v3)則是告訴串流端點將串流打包為 HLS (version3)。
3. 在 Windows PC 或 MAC 上，(您需要一個瀏覽器可以支援擴充軟體資源，像是最新版本的 Internet Explorer 或 Chrome )，您可以透過http://aka.ms/dashplayer，用來測試您的串流。
在頁面頂端貼上 DASH URL 並且選取 ”Load”。您可以在Android裝置或是Windows Phone重覆這項動作。
NOTE : DASH 撥放器也可以用來把 DASH URL 當成查詢的參數，換句話說，您可以建構一個如以下範例的URL，並且分配到不同的裝置上
http://dashplayer.azurewebsites.net/?URL=http://<您的帳號名稱>.origin.mediaservices.windows.net/../…ism/manifest(format=mpd-time-csf)
4. 在 iOS 設備上，打開 Safari 瀏覽器，並且輸入 HLS ( version3 ) 的URL，就可以直接獲取本機播放器的串流，您也可以建立一個帶有視頻標籤的 HTML5 頁面，並且給予它一個 HLS 的 URL 作為其視訊的來源，來達到同樣的效果。
當要結束一個事件時，您需要停止將串流傳入到資產中，這可以透過一個簡單的步驟來達成。
回到 Azure 管理頁面，並且選擇您所使用的通道，在最底下的工具列中，選取"停止資料串流"。這個動作將會阻止節目在您的通道中運作並且會將其刪除。
我們的即時服務所擁有的功能之一，就是我們的資產在即時或是VOD狀態是無縫接軌的，如果您現在去連接先前的URL，您還是可以發現原先的串流還是存在，但是是VOD而不是即時的。
若您想要在通道內運行其它的節目，您當然可以清除掉先前的串流。
1. 第一，透過選取 Wirecast 上方的"Steam"按鈕，停止傳送串流，之後就可以關閉編碼器。
2. 第二，回到Azure管理頁面，選取"通道"，並且選取最下方工具列的"停止通道"。當通道狀態變為"已停止"，則表示該通道並不會消耗任何的資源，當然這樣也不會有任何的費用產生。
下次您要再次使用該通道時，您可以選取"啟動通道"，此時該通道會再次的啟動，並且擁有相同的內嵌URL ( ingest URL )，這樣您就不需要重新設定您的編碼器了。
3. 最後，關於串流端點，若您想要繼續提供 VOD 的紀錄，則您需要讓串流端點保持運作。但是若您不需要，則可以進入到"資料流端點"頁面中，在最底下選取"停止"，則您的串流端點就不會再繼續運作。
在上面的文章內容中，我們已經透過 Azure 的管理頁面來進行設定、執行、移除一個即時的串流。在未來的幾天，我們將會發表更多文章，內容涵蓋了如何對使用 RTMP 的編碼器進行設定、如何使用我們的 SDK 來執行現場活動 ( live event )、如何保護影片內容的安全性以及如何進行線性串流 ( linear streams )。
我們很高興宣布Microsoft Azure 虛擬機器組件庫釋出全新優化的SQL Server 映像檔。這些預先配置好的映像檔對於交易及資料倉儲的資料負載進行優化，並分別使SQL運行於Azure VMs上擁有最佳的實務表現。
有哪些預先配置的虛擬機器映像檔可以使用?
在Azure VM組件庫中有下列四個新的預先配置的虛擬機器映像檔可以使用:
目前在虛擬機器實體上的映像檔允許附加16個data disks，用以提供最高的流量(或總頻寬)。這些實體是Standard Tier A4, A7, A8 和A9，及Basic tier A4。欲了解更多大小和選項的細節，請參考Azure虛擬機器和雲端服務大小。
如何開始從組件庫使用新的交易/資料倉儲映像檔?
透過Azure 入口網站開始使用優化的交易或資料倉儲虛擬機器映像檔
4. 在虛擬機器組態頁面中的大小選項，選擇一個可支援的大小
請注意，只有Standard tier A4, A7, A8 and A9 and Basic Tier A4可支援，若企圖選擇未支援的虛擬機器大小將會使得虛擬機器建置失敗
5. 等待虛擬機器建置完成，在這期間你可以在虛擬機器的頁面查看準備狀態。
除此之外，你可以使用PowerShell Commandlet New-AzureQuickVM來建置虛擬機器。您將會需要輸入您的雲端服務名稱、虛擬機器名稱、映像檔名稱、管理者使用名稱和密碼等作為參數。取得映像檔名稱的簡易方法是使用Get-AzureVMImage列出所有可用的虛擬機器名稱。
在交易/資料倉儲映像檔中有哪些特定的組態?
這些優化的映像檔是以Performance Best Practices for SQL Server in Azure Virtual Machines為基礎，包括以下:
交易
資料倉儲
硬碟組態
附加的硬碟數
15
儲存空間
兩個儲存池:
- 一個資料池有12個data disk;固定大小為12TB; 欄位=12
- 一個紀錄池有3個data disks;固定大小為3TB; 欄位=3
剩下的一個data disk(第16個)由使用者自行附加以及使用。
Stripe size = 64 KB
Stripe size = 256 KB
硬碟大小、快取、配置大小
1 TB each, HostCache=None, NTFS Allocation Unit Size = 64KB
SQL組態
啟動參數
-T1117當資料庫需要自動增長時，幫助維持資料檔案擁有相同大小
-T1118協助TEMPDB的可擴充性(瞭解更多)
復原模式
No change
Set to “SIMPLE” for MODEL database using ALTER DATABASE
設定預設位置
移動SQL Server 錯誤日誌和追蹤文件目錄至data disks
資料庫預設位置
系統資料庫移至Data Disks
使用者資料庫建立位置改變至data disks
即時文件初始化
Enabled
Locked pages
Enabled (瞭解更多)
FAQ
1.優化和非優化的映像檔價錢有無任何差別?
沒有。全新優化的映像檔的定價模式與非優化映像檔完全相同(瞭解更多)，不需額外的成本。注意，虛擬機器實體的大小越大，成本越高。
2.有無任何其他效能修正我必須考慮的?
有，考慮以下與SQL Server相關的效能修正
3.我要如何能夠找到更多儲存空間的資訊?
請參考儲存空間FAQ。
4.全新資料倉儲映像檔與先前舊有的有甚麼差別?
先前的資料倉儲映像檔需要顧客去執行額外的步驟，像是建立VM後需自行附加data disks，但是新的資料倉儲映像檔在建立完成後便準備完成，更加精簡，也更不容易出錯。
5.如果我想要使用舊有的資料倉儲版本，是否有辦法可以使用?
舊有的VM映像檔還可以使用，只是不能直接從組件庫存取，但您可以使用Powershell commandlets來建立。舉例來說，你可以使用Get-AzureVMImage列出所有映像檔，一但你找出舊有的
資料倉儲映像檔的描述及發佈日期，您可以使用New-AzureVM來使用相對應的映像檔。
參觀我們的Azure portal並且試用新的SQL VM映像檔，告訴我們您的感受，給予我們回饋。
透過您喜愛的社群網路頻道讓您的同事知道新的VM映像檔已經可以使用，並且別忘了在Twitter上追蹤@SQLServer，以及在Facebook上找到SQL Server專頁。
原文發表於 Azure Websites Virtual Network Integration
Azure 網站服務現在已經整合了 Azure VNET（virtual network 虛擬網路）的連接，透過 Azure 虛擬網路，您的網站就能夠存取由虛擬網路連接的其它資源，像是僅透過虛擬網路連接的虛擬機器或資料庫等，如果你既有機房透過 Site-to-Site VPN 連接到這個虛擬網路後，那這個放在 Azure 網站服務上的 Web 便能存取既有機房內的各種資源。
Azure 網站服務的虛擬網路整合需要有一個動態路由閘道以及開啟 Point-to-Site 的功能，同時這項功能目前還在預覽階段，所以僅支援使用標準價格方案的網站服務，目前標準價格方案支援 5 個網路連線，而一個網站只能連接到一個虛擬網路，多個網站連接到同一個虛擬網路是沒問題的。
要使用這個功能必須要到預覽中新的 Azure 管理介面進行設定以及瞭解連線狀況。
透過這個介面，你可以將網站連接到既有或是直接建立一個新的 Azure VNET，這個動作可以在任何時間進行建立、連接、修改或刪除虛擬網路的連線，而要注意的是選擇了正確的價格方案。
虛擬網路目前支援 TCP 及 UDP 通訊協定，同時也可以使用 VNET 中的 DNS 服務。由於混合網路連線（hybrid connection）與虛擬網路相容，而且這兩個服務在不同的應用情境上也有不同的好處，所以您可以視情況混合使用。
混合網路連線讓你可能存取遠端的應用程式，混合網路連線的代理程式可以部署在任何網路環境中然後順利地連回 Azure 的網路，這樣的功能讓你可以在不同的網路環境中存取應用程式，而不必逐一設定虛擬網路。而虛擬網路服務則是設定完成後便能自由地存取虛擬網路中的各項資源，而不必安裝代理程式，而且 Azure 提供的 Site-to-Site VPN 服務能讓企業使用既有的工具。現在 Azure 網站服務可以使用這兩種網路功能後，將會更適合在遠端連線存取的應用情境之中。
感謝北科大劉建昌同學翻譯 微軟公司 Microsoft BizTalk 團隊主管 Harish Kumar Agarwal 於 2014 年 5 月 13 日所發表的文章 http://azure.microsoft.com/blog/2014/05/13/hybrid-connections-preview/
2014 年 5 月 Microsoft Azure 推出了一項新的技術預覽功能 : Azure BizTalk Services Hybrid Connections，使用 Hybrid Connections 服務可以輕易的在 Azure 上部屬一個混合式的應用程式。
Hybrid Connections 服務是 Azure BizTalk Services 上的一項功能，用戶只需要在 Azure入口管理網站上操作，即可讓您的 Azure Website 或是行動服務可以穿透防火牆連接自己本地資料中心內的資料與服務。除此之外，為了讓您可以輕鬆的體驗這項新服務，Microsoft Azure 目前提供免費體驗 Azure BizTalk Services Hybrid Connections 的方案。
Hybrid Connections 服務支援所有 Azure Websites 所支援的程式語言與框架( .NET, PHP, Java, Python, node.js )以及 Azure 行動服務所支援之後台程式語言 ( node.js, .NET )，也支援各種微軟公司或非微軟公司之企業軟體應用系統 (LOB application)，包含許多使用特定通訊協定 ( protocols ) 之應用程式。使用 Hybrid Connections 服務時，不需要去改變網路周邊的設定 ( 不需要配置 VPN 或是新增特定之防火牆連接埠)。它提供了企業系統管理人員能夠管理與控制混合式應用程式所使用之內部資源。
透過 Hybrid Connections 服務，Azure Websites 和行動服務上的程式碼能夠如同在企業內部網路般存取本地端的資源。也因為如此，應用程式系統管理員可以簡單且靈活地，將面對外部用戶前端服務層輕易地移往 Microsoft Azure，延伸既有企業應用程式成為混合式的應用模式。
1. 從 Azure預覽入口網站 選取您的網站，並且在操作介面中選取 Azure BizTalk Services Hybrid Connections 並且點擊新增
2. 選擇一個現有的 Hybrid Connections 服務，或是創建一個新的 Hybrid Connections 服務
a. 輸入 Hybrid Connections 服務以及主機名稱，並且設定連接本地端資源的連接埠
b. 使用現有或是創建一個新的 Azure BizTalk Services Hybrid Connections 服務實例
3. 點擊 OK
一旦連接創建好之後，其狀態將顯示為 "未連接" ( Not Connected )。若要完成連接建立，則須從任何本地端的 Windows Server 主機點擊連接
4. 選擇 Hybrid connection
5. 點擊 Listener Setup
6. 在 Hybrid Connections 連接的屬性頁面，選擇 "Install and configure"，這個動作要求您做 Hybrid Connections 服務的權限設置
7. 設定完權限之後即完成 Hybrid Connections 服務的設定。
當 Hybrid Connections 服務的狀態顯示為 "已連接" ( Connected )，這就表示您的網站已經連接到本地端伺服器了。
行動服務則可以透過 Azure入口網站 進行配置 Hybrid Connections 服務。
1. 建立一個新的 BizTalk 服務，並且在 BizTalk 設定頁面上選取新增一個混合式連接 (Hybrid Connections)
2. 新增一個混合式連接
3. 選取您的行動服務，並且選擇混合式連線
4. 點擊新增混合連線，並且選擇與您的行動裝置建立連線的BizTalk服務以及混合連線
透過使用混合式連接，您現在可以在 Azure Website 或行動服務上使用相同的應用程式連接字串和 API。
舉例來說，若您要連接到一個本地端的 SQL server (payrollSQL.corp.contoso.com)
您在 Azure Website 或行動服務上可以使用相同的 SQL 連接字串 (“Data Source=payrollSQL.corp.contoso.com;Initial Catalog=payrollDB;User ID=<user>;Password=<password>”)
若想要了解更多關於混合式連接的資訊，請參照以下英文技術資源 :
· Overview: Hybrid Connections
· How-To: Connect an Azure Website with an On-Premises Resource
· Tutorial: Connect an Azure Website to an On-Premises SQL Server using Hybrid Connections
· Tutorial: Connect an Azure Mobile Services .NET Backend to an On-Premises Resource using Hybrid Connections
感謝北科大劉建昌同學翻譯 微軟公司 Microsoft Azure Websites 主管 Stefan Schackow 於 2013/12/09所發表的文章
http://azure.microsoft.com/blog/2013/12/09/ip-and-domain-restrictions-for-windows-azure-web-sites/
一個 Azure Web Sites 上的網站如何設定僅允許特定 IP 位址可以存取，或是限制特定 IP 位址不能夠存取 ? 這一直都是 Azure Websites 用戶最常問到的問題，而現在在 Microsoft Azure上終於可以實現這項功能了。 自 2013 年開始 Azure Websites 即可透過動態 IP位址限制 (DIPR) 功能，提供使用者這項攸關資安的重要功能。
開發人員可以使用 IP 或網域 (domain) 方式來控制特定 IP 位址允許或禁止存取一個 Azure Websites 上的網站，ASP.NET 開發人員可以透過設定網站上的 web.config 檔來啟用、禁用甚至是自訂特定的 IP 位址存取行為模式。
這項功能原本在 Windows Server IIS 上即有提供，這裡有一篇關於由 IIS 提供 IP 與網域限制用在 .NET Website 的概述。所有完整的組態參數和屬性都可以在 TechNet 網站上找到。
下面的程式碼範例，顯示了如何在 ASP.NET 中透過 web.config 針對 IP位址存取規則在 ipSecurity 區塊進行配置。
如過要讓特定 IP 位址與子網路遮罩 (subnetMask) 共同定義的某個 IP 位址範圍才能夠存取此網站。如下圖將 allowUnlisted 設定為false，代表只有那些被開發人員所指定的 IP 位址或 IP 位址範圍，Azure Websites 才會接受其 HTTP 請求。而在子元素中的 allowed 屬性設置為 true，表示其後由 IP 位址與子網路一同定義的 IP 位址範圍能夠允許存取這個網站。
若有一個 HTTP 請求是從不被允許的 IP 位址範圍發送到網站，此時依據 denyAction 屬性所定義，用戶會得到一個 HTTP 404 的錯誤回傳訊息。
最後要注意的是，就像 動態IP位址限制(DIPR)功能 一樣，Microsoft Azure Web Sites 此功能會依據用戶真實的 IP 位址來進行存取控制。
原文發表自 How to plan your migration to Azure Websites
把應用程式移轉到雲端平台上（順利地運作）有時候也是件不容易的事情，若您採用 Azure 網站服務來託管您的 web 應用程式，那我們有幾件事情想讓您知道，作為移轉時的參考。
目前 Azure 網站服務已經正式營運，所以 Microsoft Azure 全球的資料中心都可以提供 Azure 網站服務，這點對於想要做全球生意的您來說是相當方便且重要的，您可以參考這份清單來看 Microsoft Azure 在哪些地區提供了什麼樣的服務。
若您使用其它的雲端或是 IaaS 服務，當您架設網站時可能還要自行搭建負載平衡器（load balancer），而在 Azure 網站服務上，您不必擔心負載平衡的問題，您只需要設定要使用多少資源來運作網站，Azure 網站服務會幫您做好負載平衡，即使是跨不同區域的流量，您也可以直接使用 Microsoft Azure 所提供的流量管理員（traffic manager）來平衡跨地區的流量。但要注意的是，若您使用免費的網站服務價格方案，則並不支援負載平衡器。
結論就是：使用 Azure 網站服務來託管 Web 應用程式，不需要再另外架設負載平衡器。
Azure 網站服務的底層是由 Windows Server 以及 IIS （作為 Web 伺服器）的技術所建置而成，在這個架構上目前支援了 .NET、PHP、Node.JS、Python 以及 Java 程式語言所開發的 web 應用程式，所以關於安全性、錯誤診斷以及效能都可以完全利用 IIS 伺服器的功能來完成，詳細資訊可以參考這裡。
在 Azure 網站服務上的 web 應用程式都不該假設服務能在 100% 的時間都上線運作，請詳情閱讀 Azure 網站服務的服務水準，您會知道目前 Azure 網站服務保證了每個月 99.9% 的服務水準。
然而，若您除了 Azure 網站服務之外，還使用了其它的 Azure 或非 Azure 的服務，像是資料庫、儲存體、CDN 服務等等，那您必須也要瞭解這些服務本身的服務水準。
若您希望自己的 web 應用程式服務水準能夠超過 99.9%，那您必須要為可能發生的錯誤做好設計，以便讓網站應用程式在發生問題時，能夠自動重試或是自行復原。
Azure 網站服務目前提供了四種價格方案：免費、共享（預覽）、基本及標準。
關於價格以及詳細的功能資訊，請參考這一頁的說明。
Azure 網站服務提供平台來運作您的 web 應用程式，但您無準連線到該服務的虛擬主機進行操作或安裝特定的軟體，這是平台即服務（platform-as-a-service）的特性，由服務商直接來管理虛擬機器的部份，而您只需要專注在程式的開發即可。
當然我們建議您，開發無狀態（stateless）的 web 應用程式可以得到更好的延展性。
目前只有選擇標準價格方案才能使用自動延展（Auto-scale）的功能，這可以幫助您省下自行監控及手動操作的力氣，費用上也較有效率，因為自動延展機制會根據狀態自行幫您挑選合適的運算資源，以免造成浪費或平足，詳細的資訊可以參考這篇文章的說明。
Azure 網站服務中，每一個 Web 實體都有本地端的磁碟空間，不過這個磁碟伺服器是在同一個 Web 服務下各實體間共享的，所以同一個 web 下的各實體都可以共享像是 session、cache 之類的資料。
Azure 網站服務針對 PHP 應用程式提供了 Wincache ，而 IIS 伺服器也設定了 Output Cache 讓所有放在 Azure 網站服務上的應用程式享用到這個快取。
在大部份的狀況下，這樣的快取機制已經足夠，但如果您需要更高等級的快取，您可以選擇：
Azure 網站服務在標準的價格方案下，提供了部署預備環境（staging）的機制，您可以在網站開發完成後，先部署到預備環境，待測試沒有問題之後，直接在不停機的狀況下立刻切換上線，詳細的操作可以參考這篇文章。
為了讓瀏覽器與網站之間的通訊更安全，我們會使用 HTTPS 通訊協定來進行資料傳輸，這時就必須使用 SSL 加密技術，Azure 網站服務可以讓您直接設定好 SSL 連線，詳情請參考這篇文章。
當您建立網站服務時，Microsoft Azure 會提供給您一個網域名稱像是：http://<mysite>.azurewebsites.net 來使用，而當然您也可以設定自訂的網域名稱，詳細的內容請參考這篇文章。
Azure 網站服務不只是能執行網站應用程式，也能透過 WebJobs 來背景執行一些批次的工作，詳細的使用請參考這篇文章。
在 Azure 網站服務中開啟了自我修復的功能後，您的網站就會自動偵測是否有狀況發生，以及嘗試進行復原，詳細的設定及功能請參考這篇文章。
Azure 網站服務提供您可以很方便地自動或手動進行網站內容的備份及還原，您不僅可以回溯到之前的網站，也可以用備份的內容建立新的網站。
關於網站備份的部份，可以參考這篇文章；而這篇文章則說明了如何從備份中進行還原。
Azure 網站服務本身並沒有提供 SMTP 的服務來寄送信件，您可以使用像是 SendGrid 這樣的服務來寄信，價格方案可以參考這裡，而這篇文章也說明了要如何設定 SendGrid。
在 Azure 網站服務上有很多種架構設計的方式，這篇文章只是特別提示幾個重點，希望可以協助您部署成功的網站服務。
2014年4月宣布了新的 Microsoft Azure SQL Database 服務來取代既有的 Microsoft SQL Database Business/Web Edition。2014 年 8 月 26 日 SQL Server 產品主管 Eron Kelly 宣布新版本 Microsoft SQL Database Basic, Standard 與 Premium 版已經於 2014 年 9 月11日脫離技術預覽階段，開始正式營運 ( http://azure.microsoft.com/blog/2014/08/26/new-azure-sql-database-service-tiers-generally-available-in-september-with-reduced-pricing-and-enhanced-sla/ )，新的雲端資料庫服務，與過去版本相較有了以下的改善 :
與傳統 Microsoft SQL Server 規劃相較，客戶 Microsoft Azure SQL Database 不同等級的選用，可以參考 http://msdn.microsoft.com/library/azure/dn369873.aspx，在此節錄最重要的表格。
Azure SQL Database 等級
Database Throughput Units (DTUs)
單一資料庫容量上限 (GB)
Worker Threads 上限
Sessions 數上限
預期效能
資料庫庫吞吐量單元（Database Throughput Unit ,DTU）：這是一個綜合多項能力的單位，結合了 CPU，記憶體，資料讀寫能力成為一個單位。 理論上 5 DTU 的效能水準比 1 DTU 要多五倍，Worker thread 在邏輯上表示 Microsoft Azure SQL Database 允許的執行緒數量上限，可以視為是作業系統允許的執行緒數量上限，隱身在資料庫服務背後 ；Worker thread 默默地執行資料庫服務所指派的工作。而 Sessions 數則是指邏輯上伺服器端與用戶端所建立能夠交換資料的單位，Session 數實際上並不等同於實體上網路 Connection 連線數，但兩者間數量差異不大，可以視為是能夠允許的網路連線數量。雲端服務的特質在於資源共享，資源共享也意味著必須限制單一用戶的用量，以避免其他租戶使用時受到影響，因此在資料庫規劃上需要隨時注意相關資訊。
原文發表於 Azure HDInsight makes HBase (NoSQL database) a GA Feature
在 2014 年 6 月，我們在 Azure HDInsight 中提供了 HBase 的預覽服務，而在 8 月 21 號，我們正式推出 HBase 的服務（同時也釋出了包含了像是 Azure DocumentDB、Azure Search 等服務）。Apache HBase 是 Apache Hadoop 生態系中，一個基於行式（columnar）的 NoSQL（Not only Structured Query Language）分散式資料庫的專案。
HBase 在 Apache Hadoop 生態系中提供了資料交易操作的功能，讓用戶能夠迅速地在 Azure Blob 儲存體中儲存資料，以及從大筆的資料中進行查詢。由於是分散式的資料庫架構，HBase 能夠依據負載及效能的需求來延展，所以 HBase 非常適合需要處理數以幾百萬或幾十億資料量的用戶（正式營運後，Azure HDInsight 中的 HBase 能支援 Azure Blob 儲存體中 500 TB 的資料），當然，HBase 缺乏了一些像是優化功能、第二層索引、以及進階的查詢語法，所以無法取代現有的關聯式資料庫管理系統（RDBMS）。
關於 HBase 一些常見的應用包括了：
我們在 Azure 的官方網站上提供了許多關於 HBase 的學習資料，歡迎您多加利用：
另外，如果您想瞭解關於 Hadoop 以及 HDInsight 可以參考下列資料：