Microsoft Azure 提供的網站服務，讓網站開發人員可以將自己用 ASP.NET、PHP、Node.js、Python 以及 Java 所開發的網站應用程式，部署到雲端平台來提供服務，享受雲端平台的彈性擴充、隨用隨付的概念及便利性，而且更重要的是，除了支援多種程式語言之外，也支援多種部署方式，所以並不限制要使用哪一種作業系統來做為開發環境。
這堂線上課程主要是介紹如何把 PHP 網站部署到 Microsoft Azure 的網站服務中，瞭解運作的環境以及部署方式，另外也會提到在 PHP 程式中如何使用 Microsoft Azure 上的 MySQL 服務（由 ClearDb 提供）以及 Microsoft Azure 本身提供的 SQL 資料庫服務。PHP 網站開發人員，可以透過 http://aka.ms/mva-azure-php 來觀看這堂課程。這是由我親自錄製，所以是中文的影片、字幕以及投影片，有任何問題也請與我聯絡，謝謝。
原文發表於 Migrating Azure services to new regions
最近我們接到了需要將資料中心從美國中南部移到美東的客戶需求，該工作包括計劃一個適合的 SKU，以及有效利用地理複寫 (Geo-Replication) 的高可用性和可回復性。
客戶試圖整合他們 Azure 服務，並遷移之，其中最重要的需求是資料庫的預期停機時間，他們希望停機時間越短越好，不可超過6小時。
客戶概觀
此客戶是個社交手機遊戲 (可按地理位置搜尋) 的開發商，該遊戲存有世界各地知名的城鎮，玩家於遊戲中會選擇他們所在的地理位置。
計畫
從計畫的角度來看，我們考量了多個選項。這些都不是特別長的討論，但值得思考和關注的問題點，且通常都是必要的討論。
該客戶是最重視的是移動性，因此我們必須擁有相當足夠地於經緯度數量。
該資料庫約 35 GB，而其中約 5 GB 的資料被認為是於轉移過程中需保持 online 狀態，其餘的資料則可於 offline 狀態下進行添加。
該資料庫是企業版的 SKU，且並沒有使用任何具體 Azure 功能。
他們可以容忍長達 8 小時的停機時間，但若停機時間可小於 2 小時，是企業及消費者的期望。當然每週有特定的時間點是最適合停機的，因此停機時間控制是一個可被設計的需求。
客戶是成本導向的，但願意瞭解屏除成本考量外的任何方案。
客戶對於 DBCopy 過程是相當謹慎的，並認為資料的 import/export 時間若超過 10 小時，將造成嚴重損失。
計算節點的轉移不是主要考量，也不是迫切地需要將現有的 Blob Storage Data 轉移，解決方案是建構像是 No Cross DC Logic，以便訪問現有的 Blobs。
解決方案包括：
首選是「啟用地理複寫功能」，原因是：
比較值得注意的是，該服務是預覽版，但這被認為是一個容忍的風險。於分析歷史資料後，決定一個 P1 就足以滿足他們的需求。另外不可避免的風險是，複製過程是否會佔用過多資源，但這被視為是特殊事件，畢竟可預期的資源需求不高，故最後還是決定保有 P1，並隨時準備升級到 P2。
於容量規劃過程中，客戶是參考「變更資料庫服務層和效能層級」決定 SQL Azure 資料庫的版本。
執行
客戶必須註冊為 Premium SKU 預覽，這必須通過 portal 花幾秒鐘的時間完成。
一旦簽約，該資料庫可升級到 Premium，請參閱「更改資料庫服務層級和性能水平」。以下公式實際上是相當準確的，預估升級時間為 12 小時：
3 * [ 5分鐘 + 資料庫大小 / (150 MB/分鐘) ]
接下來的步驟是建立理想中的複製區域，即美國東地區，這部分較難預估需要多長時間，也較難預估即將開展的副本所需資源。這些步驟可參考「設定作用中地理複寫 (連續複製)」。
值得注意的是，這個執行計劃是基於程式碼間的部署，若過程是純技術性的，大多於 24 小時內完成。但客戶選擇多等一兩天再執行計畫的下一步，其理由是完成特定程式碼的修改，而發生在現有的拓撲不是在一個新的數據中心。他們關心DDL更改是否會被複製。所有的更改都將被複製，除了於更新主資料庫後必要的更動，像是登入設定等。這些必須在每個環境中進行，而使用者的創建可在 source 完成，詳情請參見「作用中地理複寫的安全性」，將具體說明登入相關議題。
最後一步是切換到新的區域。以下步驟是客戶特別分享的經驗談，提供給未來可能負責此工作的 IT 專業人員們。對於終止作用中地理複寫，可參考「終止連續複製關聯性」一文。
以下為客戶完成此偉大工作後的經驗談：
「轉移非常順利，我們停機約 1 小時，其餘大部分時間是在等待我們的新程式碼部署，配置更新和 prod / staging 的互換。中止 Azure DB 的複製和改變 read / write 模式是相當簡單的過程。」
本文原始發表於 TechNet 台灣部落格
原文發表於 Backup for Azure Web Sites is now generally available
Azure 網站服務最近有了新的更新——網站的備份還原功能脫離預覽階段，正式對外提供服務。而正式推出後，也會增加一些功能。
首先，備份的部份支援更大的網站內容，同時我們也排除了一些可能會造成備份失敗的狀況，像是備份時檔案被鎖定等等。
而現在您也可以透過預覽的新 Azure 管理介面來操作網站備份及還原的服務，在網站頁面可以看到備份的狀態，並且直接啟動備份的功能。同時也能設定備份的保存時間，而不必手動或自己寫 script 來刪除舊的備份。
另外一個重要的改良是你可以從任何一個備份來還原網站內容，提供更多的彈性。
這些改變將提供您更有彈性地備份或還原您的網站服務。
我們興奮地宣佈 Microsoft Azure StorSimple 解決方案，將於 8 月 1 日開放，此項新的服務，建立於既有已成功的 StorSimple 上，提供自動化並消除長久以來 IT 組織的一大困擾 – 資料的倍數成長所導致的存儲容量不足、資料安全性疑慮等問題。Mazda, SK Telecom, Paul Smith, Sundance Film Festival, GF Health Products, Black and Veatch 等世界各地的客戶都已利用 StorSimple 混合雲存儲解決方案來簡化他們的存儲基礎架構。
全新的 StorSimple 8000 系列混合存儲陣列是前所未見最強大的 StorSimple 系統，並更緊密地與 Azure 集成，包括了以 Azure 為基礎延伸出來的兩個新功能，將讓使用者可以進行集中資料管理。這些新的解決方案將說明微軟是如何基於雲端運算，來提供客戶最好的存儲位置，並降低 40% - 60% 的存儲成本，協助 IT 團隊將重點轉移至業務戰略，而不是僅從事基礎設施管理。
新的 StorSimple 8000 系列陣列有兩種選項，來滿足各種容量和性能的需求：StorSimple 8100 和 StorSimple 8600，你可以下載此檔了解更多，這些都是企業混合存儲陣列的應用，而不是過往侷限於唯一 SSDs 和 HDDs，這些陣列使用 Azure Storage 作為一個自動產能擴張和異地資料保護的混合雲層。這代表 IT 團隊不再需要花那麼多時間和精力，致力於不可避免的存儲容量升級，或管理複雜的資料保護細節。StorSimple 8000 系列陣列透過 Cloud Snapshots，將自動保存異地資料，填補原本問題層出不窮的硬碟存儲及昂貴的遠端複製兩個方案間的巨大差距。
全新的陣列將帶領你看到 Microsoft Azure StorSimple 的虛擬裝置，它是將 StorSimple 技術導入雲端作為 Azure 虛擬機器的運行。透過一個匹配的 Azure StorSimple 虛擬機器，StorSimple 8000 系列的客戶可以在 Azure 上執行應用程式，進而搜索與分析歷史資料庫，過程均不用中斷他們的資料中心的生產工作。此新的 StorSimple 虛擬裝置不僅適用 Windows Server和 Hyper-V 的資料，甚至 Linux 和 VMware Servers 也適用，也就是說，將為現在所有常見的伺服器平台，提供混合雲功能。
虛擬裝置也有雲端災害復原 (Disaster Recovery, DR) 功能，它將資料存儲在客戶資料中心內的 Azure StorSimple 陣列，可以將虛擬機器重新開機，並訪問先前上傳的資料。資料在恢復作業運行期間所作的任何更新，都於 StorSimple 陣列恢復正常作業時進行下載。
災難復原是受到很多客戶重視的，但他們很少能有機會來測試自己的能力。Microsoft Azure StorSimple 8000 系列陣列和虛擬裝置有個「即時恢復」的功能，讓應用程式和終端用戶可以於災難發生時儘快訪問資料，並加速還原，繞過不必要的資料僅下載重要資料。
在此版本中的另一項突破性的功能是Microsoft Azure StorSimple Manager，它整合管理所有客戶的 Azure StorSimple 8000 系列陣列和虛擬裝置。管理員將透過此管理器來集中控制雲端 StorSimple 存儲和資料管理等各項功能，所以可以跨越整個企業，確保一致的操作和資料保護/保留原則。新的 StorSimple Manager 還為管理員提供了顯示即時狀態的儀表板，使管理員可以快速發現存儲的問題，使 IT 團隊可以花更少的時間在存儲基礎設施的管理與商務應用程式的資源移轉。
StorSimple 的客戶已體驗到這幾年來 StorSimple 所帶來的財務及 IT 效益。現在，Microsoft Azure StorSimple 解決方案帶來的創新，將提供更強大的運作效率，而這是技術開發與混合雲設計結合的偉大範例。
如果你有興趣學習更多，請在這邊下載電子書或是要求示範。
本文原始發布於「TechNet 台灣部落格」
在上個月，我們宣佈支援部署 Docker 上 Azure 虛擬機器上，並且應用我們的技術，讓客戶能夠盡快地使用 Docker 的威力。為了持續為我們的客戶提供更好的支援，我們宣佈將與 Google 及 Docker 合作，預計將在 Microsoft Azure 上支援 Kubernetes 及 libswarm 這兩個開源專案。
Kubernetes 這個專案發表於今年六月份，它是一種「宣告式容器管理解決方案」，原本是在 Google Compute Engine 上管理 Docker 的工具，在 Microsoft Open Technology 於這個專案的 GitHub 專案上的貢獻後，也讓這項工具支援在 Microsoft Azure 的 Linux 虛擬機器上運作。這讓使用 Microsoft Azure 來建置 Linux 虛擬機器的用戶多了一個管理工具的選項。
同樣地，MS Open Tech 也開始貢獻 Docker 的命令式管理工具 -- libswarm 專案，Microsoft Azure 也有了原生的支援，能夠在 Azure 虛擬機器上部署 Docker 容器。
這項宣佈呼應了我們 Microsoft Azure 一貫對客戶的承諾 -- 回應客戶的需要，並且支援多樣的系統、技術及語言（從 Windows, SQL, .NET 到 Python, Ruby, Node.js, Java, Hadoop, Linux, 以及 Oracle ），讓客戶能夠快速在 Microsoft Azure 提供的公有雲服務上建置及部署應用。同樣我們也持續打造 Microsoft Azure 為開放的平台，如同最近宣佈支援的 Puppet, Chef 及其它開源專案一樣。在 Microsoft，我們一向看重與開發人員、合作夥伴以及客戶在複雜 IT 環境的需求，也期待能從您的需求中瞭解什麼對您是最重要的事。