我們正在將AWS MapReduce從我們自己的機架上遷移到Hadoop集羣。最初我們將有7臺專用於Hadoop/HDFS的服務器。擁有7臺服務器的Hadoop架構 - 平衡連續性和性能
我們在HDFS上存儲的數據將是關鍵任務，我不希望我們有備份選項（至少不是在我們使用的第一天），所以我想盡我所能保證連續性。
我還想充分利用我們的計算能力，因爲我們有的工作可以輕鬆使用雙倍的硬件。
我們到底做了什麼是這樣的：
使用LXC（LXC是關鍵部件在這裏），我們在管理組件的兩臺服務器上創建了獨立的容器，比如job manager，namenode和其他各種服務器，因爲namenode和job manager是最耗費資源的，我們在這兩臺服務器之間分配它們（每個組件擁有獨立的LXC容器）。我們在這兩臺服務器之間分配的其餘組件。
然後，我們爲這兩個「管理」服務器中的每一個部署了一個「簡化」數據節點和任務跟蹤器。我們使用LXC的控制組以犧牲數據/任務節點爲代價給管理組件提供CPU和磁盤優先級。我們使用Cloudera Manager的簡化配置輕鬆地將減少數量的任務插槽部署到這兩個盒子上的數據/任務節點。
通過這種方式，我們充分利用硬件，其餘的盒子都是專用的「正常」數據/任務節點。
我們當然有一個備份名稱節點在作業跟蹤器的同一臺物理主機上運行，而第二個物理盒上的主名稱節點有這個備份。我們還在3臺工作站機器上的LXC容器中安裝了一個使用空間NTFS客戶機，並讓namenode將配置副本作爲進一步備份寫出。
我們沒有將名稱節點（硬盤故障）放鬆一次（磁盤），並且能夠成功從輔助節點恢復它。
我們將嘗試使用LXC容器來分隔各個進程（任務節點，名稱節點，輔助名稱節點，主節點），並將名稱節點，輔助節點和主節點與任務節點重疊（如同這些服務器所有的都有一個大的磁盤和比名稱節點或主節點需要更多的cpu +內存）。我們將使用cgroups來保證master和namenodes的資源。我們將來會在我們嘗試過的時候自己回答這個問題。 – 2013-03-26 05:02:21
你有沒有去實現這個？ – cabad 2013-10-17 21:06:05