預構建Linux映射在Windows Azure中部署多節點Hadoop群集

本文章由 HTTP://www.aliyun.com/zixun/aggregation/13357.html">Azure CAT 團隊的 Piyush Ranjan (MSFT) 撰寫。

隨著基礎結構服務（虛擬機器和虛擬網路）近期在 Windows Azure 上正式發佈，越來越多的企業工作負荷正在向公共雲遷移，以利用雲經濟效益、規模和速度。 我最近參與了其中一種企業工作負荷 - 雲中的大資料。 在此，我將與您分享一些提示和最佳做法。

該專案要求使用預構建 Linux 映射在 Windows Azure 中部署多節點 Hadoop 群集。 我使用 Windows Azure 鏡像庫中的 CentOS 6.3 映射配置了一個中型虛擬機器 (VM)，並繼續部署單節點核心 Hadoop。 一切都很正常，只是當我開始測試稍繁重的工作負荷時，我發現 VM 會經常凍結或變得反應遲鈍。

不難看出，這與中型 VM 的資源有關 – 畢竟它只有 2 個 CPU 核及 3.5 GB 記憶體。 但是，我沒想到整個 VM 會變得反應遲鈍甚至開始掉線。 在與我的朋友和同事討論此問題之後，我們確信是因為 VM 根本沒有配置交換空間（即，Windows 上所說的分頁檔）。 因此，當記憶體壓力增加時，其虛擬記憶體系統無法交換至磁片。

您可以檢查系統如何通過在 Linux shell 提示符下運行「free」命令來查看系統如何使用記憶體，尤其是，您可以使用「cat /proc/swaps」查看交換空間的狀態 – 配置的記憶體大小，以及正在使用中的記憶體大小。 請參閱下面的螢幕截圖。

預設情況下，對於在 Windows Azure 虛擬機器中配置的 Linux VM，根本未配置交換空間, 因此「cat /proc/swaps」不會返回任何內容，同樣，「free」命令不會顯示任何正在交換的活動。

一個有趣的問題是，為什麼使用 Linux 庫映射（即來自 Windows Azure 鏡像庫的映射）的 VM 配置不會自動設定交換空間。 我們思考了一下發現這是因為使用者應該決定交換空間的大小和位置並進行後期配置。 但是，很有可能出現這種情況：某位使用者持續使用從未配置交換空間的 VM，直到進程開始崩潰或 VM 凍結。

也就是說，一旦我們意識到我們需要做的就是配置交換空間，便立即按照一系列簡單步驟在資源磁片上配置基於檔的交換空間；Windows Azure 中的中型虛擬機器配備 135 GB 的資源磁片，安裝為「/mnt/resource」。 下面介紹在 VM 上配置基於檔的交換空間的步驟。

使用「fallocate」命令分配適當大小的交換檔，如在資源磁片上分配 5GB。 語法為：「fallocate -l 5g /mnt/resource/swap5g」，其中「swap5g」是檔案名 使用「chmod」命令更改檔的許可權，確保只有root使用者具有交換檔的讀/寫許可權。 語法為：「chmod 600 /mnt/resource/swap5g」 使用「mkswap」命令將檔設置為交換區域。 語法為：「mkswap /mnt/resource/swap5g」 使用「swapon」命令啟用交換檔。 語法為：「swapon /mnt/resource/swap5g」 現在，交換空間可供使用，並且通過「cat /proc/swaps」命令應該可以進行確認。 向「/etc/fstab」檔添加條目，這樣即使 VM 在 Azure 中進行回收，仍可保留交換設置。 語法為：echo 「/mnt/resource/swap5g  none  swap  sw  0 0」 >> /etc/fstab

下圖是在我的 VM 上執行上述命令的記錄。

鳴謝：感謝我的同事 Amit Srivastava 説明我排查和解決交換問題。