Azure 點亮 Microsoft Ignite 2015 盛會

本週在 Ignite,微軟雲端與企業事業群的副總裁 Brad Anderson 勾勒了在今天行動優先,雲端至上的目標製作智慧雲端的關鍵特徵。一個智慧雲端平台需要能受信任,具靈活性與整合性。Azure 是一個迅速創新的平台,並在這些核心原則下於最近的 12 個月推行,我們能驕傲的說我們加入了超過 500 個功能與服務到這個平台內。但是 Azure 的亮點並不只是我們所加入的這些創新,而是由你—我們的客戶與合作夥伴—在這個平台上所建構的應用。從 3M 使用 Azure 加速行動應用的開發,到海尼根執行它的全球行銷宣傳,以及 GE 的健康照護傳遞了靈活的健康保護應用程式,我們看到客戶運用了 Azure 的威力來開發出令人驚艷的事物。 今天我們很高興可以聚焦在數個令人興奮的宣佈,將讓你能運用 Azure 做更多的創新,帶著 Azure 的能量到你的資料中心,以及取得在雲端,平地或混合情況中都一致的體驗。 在你資料中心內的 Azure 讓 Azure 具有威力的其中一個特性是超擴展能力,它運行的同時也和構成它的技術持續相互影響。憑藉我們對於混合架構的基本信念以及在跨地點間提供高度一致性的承諾,我們將 Azure 技術與本地解決方案進行整合,讓你能獲得選擇運行你的工作負載卻不需妥協的靈活性: 運用今天宣佈的 Microsoft Azure Stack,你將能夠將與 Azure 相同基礎的程式基礎帶進你的資料中心,讓你能在應用程式不論是在你的資料中心或是在 Azure 雲端都能選有非常高度的一致性。你可以得到像Azure 資源管理員 (Resource Manager) 一樣的經驗,以讓你能使用宣告式範本 (declarative templates) 建立與管理應用程式,套用以角色為基礎的存取控制 (RBAC) 規則,以及標記資源。 Windows Server 2016 第二版技術預覽帶給你容器技術 (container technologies) 的威力,像是…

2

TechNet 論壇精選 (9/12 – 10/7)

TechNet 論壇是一個可以讓 IT 專業人員們自由提出問題、尋找資訊的好地方,歡迎大家多多利用,與論壇社群中的同好們一同分享 Microsoft 技術資訊。 而我們也會不定期整理一些論壇精選給大家,希望對您的學習有所幫助!以下為 9/12 – 10/7 的論壇精選喔,感謝 TechNet 小幫手的協助。 標題 日期 企業 File Server Resource Manager 2008 R2 政策及空間配額管理建議 2014/9/12 Windows 2008 是否不支援 VBScript 修改 AD Account 密碼 2014/9/16 Exchange 2010 與 2013 共存問題 2014/9/18 Outlook 2010 行事曆資源排程問題 2014/9/19 Windows 2012 安裝大量啓用工具後有問題 2014/9/22 IIS 網站找不到… Ping 網域找不到… 但 Ping IP 位址是 OK…


案例分享:遷移 Azure 服務至新區域資料中心的過程及步驟

最近我們接到了需要將資料中心從美國中南部移到美東的客戶需求,該工作包括計劃一個適合的 SKU,以及有效利用地理複寫 (Geo-Replication) 的高可用性和可回復性。 客戶試圖整合他們 Azure 服務,並遷移之,其中最重要的需求是資料庫的預期停機時間,他們希望停機時間越短越好,不可超過6小時。  客戶概觀 此客戶是個社交手機遊戲 (可按地理位置搜尋) 的開發商,該遊戲存有世界各地知名的城鎮,玩家於遊戲中會選擇他們所在的地理位置。 計畫 從計畫的角度來看,我們考量了多個選項。這些都不是特別長的討論,但值得思考和關注的問題點,且通常都是必要的討論。 ◎ 資料庫多大? ◎ 目前資料庫的 SKU 是? ◎ 你能容忍的停機時間是多久? ◎ 你可容忍多少資料於轉移過程中遺失? ◎ 你的預算? ◎ 你是否能容忍使用最近發佈或是仍在預覽階段的服務? ◎ 對於資料移轉是否有什麼特別的顧忌? ◎ 什麼是你不擔心的? 該客戶是最重視的是移動性,因此我們必須擁有相當足夠地於經緯度數量。 該資料庫約 35 GB,而其中約 5 GB 的資料被認為是於轉移過程中需保持 online 狀態,其餘的資料則可於 offline 狀態下進行添加。 該資料庫是企業版的 SKU,且並沒有使用任何具體 Azure 功能。 他們可以容忍長達 8 小時的停機時間,但若停機時間可小於 2 小時,是企業及消費者的期望。當然每週有特定的時間點是最適合停機的,因此停機時間控制是一個可被設計的需求。 客戶是成本導向的,但願意瞭解屏除成本考量外的任何方案。 客戶對於 DBCopy 過程是相當謹慎的,並認為資料的 import/export 時間若超過 10 小時,將造成嚴重損失。 計算節點的轉移不是主要考量,也不是迫切地需要將現有的 Blob…

6