本文章是由機器翻譯。

編輯備註

在定域機組的標頭

Howard Dierking

fig01.gif

有幾週前, 我有相當技術 scare 在家。 我的網路檔案伺服器上的硬碟失敗,並且我幾乎會遺失系列的相片 (像這個) 的數個月的價值。 ironic 的整個事件棒,是我有我的網路伺服器設定為備份到在定域機組中執行的服務。 所有我必須執行,我以為,已將所有檔案都儲存在該伺服器,因此我必須永遠不會擔心會再次遺失資料。 我無法考慮,但是,是我備份的服務限制 150GB,和我啟動新增至我的清單,資料的系列視訊之後,所需的備份,我快速超過此限制。

Fortunateley,我無法使用某些魔法,取得它回到可行狀態夠長複寫到另一個磁碟機,資料和磁碟機上。 不過,經驗保留我相當而以確保我有不只是良好備份策略位置,但良好的整體資料管理策略。 這表示我已通過的所有資料,我在我的網路上儲存,並讓蓄意決定所需要發生的。 例如,我保留音樂和相片網路伺服器上因為這些共用我的系列的多個成員之間。 不過,我花所有我的我的伺服器的程式設計專案 — 事實,完全關閉的我的網路 —,它們移到在定域機組中執行裝載的版本控制系統。

轉寄存在日期,我了已花費在相當時間研究目前的電腦技術,以及我早期的經驗,在技術範例 Remind 使用我的其中一個主要的 takeaways,從 [我最近的 Microsoft 的定域機組發行幾乎資料遺失。 簡單地說移動至定域機組是不應該盲目地完成的。 確定,您可能無法取得您現有的 Web 應用程式] 及 [服務和它們直接部署至 Windows Azure,並它們會可能執行正常,就像它們可能正常上執行您目前的硬體。 不過,查看定域機組這樣 — 只要硬體的進一步 commoditization 為 — 為,我相信,出遺漏,在嚴重查閱我們現有的應用程式架構,並將找到的位置,我們可以變更平台更好使用一些實際的機會。

例如,我已聽在討論如何運用 Windows Azure 佇列,和如何這種技術應該會影響整體的應用程式架構上的最近。 結果是,不應該外部的原則,非同步服務會收到一個訊息,而且將它放入一個背景工作佇列,它會稍後會讀取並處理不同的服務。 不過,elastic-縮放定域機組平台的實際上,善加利用這個平台的元件可以讓其中一個多個獨立的可調整的單位的工作和這樣做,比多"all-or-nothing 」 樣式中資料分割的應用程式更更有效率地縮放。 從商務角度來看時您的成本根據您的應用程式需要的資源, 架構移位,像這樣就會是不只是學術的練習。

另一個主要主題的 [我已從 [我最近的 [參考資料] foray 至定域機組運算技術 reemerged 是資訊的如果您是資訊的開發人員這些日期,只是的龐大數量來吸收並套用。 此外,這種技術是沒有意義,除非您就可以在您目前的專案中套用它們。 因此,我很高興宣佈我們所啟動的 [我希望是許多 brownfield 開發系列中的第一個。 第一個數列中可能會啟動而且會執行每週在線上,MSDN Magazine 著重於現有的 ASP.NET 應用程式並使其到豐富型網際網路應用程式 (RIA)。 我希望採取這個相同的模型,並使用它其中一個的應用程式有效地運用定域機組的重整的主題的主機上建立進一步的系列。

請造訪我們在 msdn.microsoft.com/Magazine. 疑問、 意見或 MSDN Magazine 建議嗎? 傳送到編輯器: mmeditor@Microsoft.com.

感謝到文章提供,Microsoft 技術支援專家: 協助解決問題 Paul Andrew、 Arkadi Brjazovski Pablo Castro、 Sandu Chirica、 Fred Chong、 Andy Conrad、 Mike Flasko、 Phil Haak、 David Hill、 Jason Hogg、 Nataraja Koduru、 Bertrand LeRoy、 Steve Marx、 Eugenio 依照的進度和 Chester Smith。