如何在Filer上即時查詢那幾個CIFS client的Loading最大

一般來說我們都會將Filer上資料夾，透過CIFS分享給Windows Client使用，不過有時候碰到Filer上的CPU與CIFS OPS突然衝高，但是卻不知道是那幾個Client的用量造成的，這時候我們可以透過"cifs top"這一個指令來查看，使用的方法介紹如下：
1. Telnet/SSH到Filer上，下"cifs top"這一個指令，如果show出以下訊息：
   The cifs.per_client_stats.enable option must be on to use "cifs top"，就表示該功能尚未啟用。
2. 啟用該功能，請下"options cifs.per_client_stats.enable on" 。
3. 下完上述指令之後，需要等一會讓Filer去收集資料，然後在下"cifs top"，可以看到以下
    資訊：
     ops/s  reads(n, KB/s) writes(n, KB/s) suspect/s   IP              Name
     4304 |      0     0 |       0     0 |        0 |            172.19.2.88        AAA\tom
     3732 |      0     0 |       0     0 |        0 |            172.19.2.118      AAAY\david
     3475 |      0     2 |      27  1769 |        0 |       172.19.2.110      AAA\lin
     3439 |      0     0 |       0     0 |        0 |            172.19.2.67        AAA\cindy
     3148 |     21   685 |       0     0 |        0 |        172.19.2.46        AAA\jimmy
    後面的Name欄位，我有修改過，如果公司有網域的話，會帶網域\使用者帳號。
4. 其他參數請參考指令網址。

進行NetApp Volume Resize碰到的問題

1. 在管理公司的NetApp Storage時，給User使用的Volume空間，我個人的習慣是不會把空間全部一次開到滿，而是定期Monitor空間的成長狀況，然後等到空間使用到80~90%時，再去增加空間，這沒有一定，要看個人與公司的管理方式而定，所以恰巧剛好碰到機會要把User的Volume開大，透過GUI去把Volume Resize放大，結果卻出現以下錯誤訊息：

實際發生原因為我目前線上的這台NetApp Storage，之前曾經為了移轉資料，而跟別台NetApp Storage做過SnapMirror同步的關係，這時只要下一行指令即可進行Volume Resize，
指令為：vol options data fs_size_fixed off 

解決ESXi主機中的Guest Host非預期性restart問題

1. 最近這一陣子發現有某幾台Window Guest主機總會在半夜自動重新啟動，檢查各台主機的eventlog都出現以下的錯誤訊息，都是Server自動重新關機後在重新啟動，當下以為是Server作業系統有問題，但反覆check以後，也沒發現哪裡有問題，另外從eventlog中也看不出啥鳥問題？

2.  隨後在連到vCenter中去檢查Event，然後把Server發生重啟的相對應時間的Event，整個export出來分析比對，我節錄主要兩個Key Word訊息如下：
*yourservername on youresxihost in cluster yourclustername in yourdatacenter reset by HA. Reason: VMware Tools heartbeat failure. A screenshot is saved at /vmfs/volumes/93a8a5f4-e161a15a/yourservername-screenshot-0.png

*Alarm 'Virtual machine high availability error' on yourservername changed from Gray to Gray
Alarm 'Virtual machine high availability error' on yourservername triggered an action
Alarm 'Virtual machine high availability error': an SNMP trap for entity yourservername was sent
從上面看出一些端倪，應該是VMware Tools heartbeat出了問題，翻了一些官方文件，找到以下兩個連結，可以提供參考：
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007899
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027734
發生主要原因是在Guest OS上，我們都會安裝VMware Tools這一隻程式，而如果在你的vCenter中的Cluster setting裡，如果有Enable VM Monitoring功能，則在ESXI主機上的Host agent會依照你設定的條件去跟Guest OS上VMware Tools去做heartbeat溝通，而一旦ESXi主機沒有收到Guest OS的heartbeat，就會判定Guest OS已經掛了，然後進行重啟，以下是我原本的VM Monitoring設定：

 

可以看到，原本的Monitoring sensitivity是設成High，後來SI建議我把他設成Low，或者是把VM Monitoring功能關閉，以避免ESXi造成誤判，把原本活的好好的Guest OS，硬把它認為已經掛了，結果造成非預期性重開情事再次發生。

解決VDR Restore無法刪除問題

1. 最近在測試VDR，發現一個怪問題，就是想要刪除一些測試的Restore檔案，卻怎麼也刪除
    不掉，即使已經選擇了Make For Delete，如下圖所示：

2. 後來請教了SI，並且參考以下兩篇連結：
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013387
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1029296
作法是這樣，到VDR的Confoguration選項裡的Destinations，選擇你的VDR備份路徑，按右鍵選擇 Integrity check。

3. 選擇Yes，手動讓VDR去把備份路徑重新掃一遍，之後最會發現，有Make For Delete的Restore檔案，已經被刪除。

NA與DC時間不同步解決方式

話說某天早上，在NetApp FAS2020上的CIFS Share忽然全部都無法存取，telnet到設備上檢查，一切看起來都還滿正常的，後來再打電話跟SI詢問，結果廠商提醒可以檢查一下FAS2020上的時間跟DC的時間是否有同步，忽然恍然大悟想到，隨即telnet到NA上，下date指令一看，跟DC的時間差了快5分30幾秒，難怪client會連不到CIFS Share，因為FAS2020跟DC已經相差超過5分鐘以上，以致於FAS2020早已跟DC失去聯繫，所以client會無法進行驗證，重新設在設定一下FAS2020上的時間相關設定如下：

fas2020> options timed ?
Setting invalid option timed failed.
timed.enable                 on
timed.log                    off
timed.max_skew               30m
timed.min_skew               0
timed.proto                  ntp
timed.sched                  1h
timed.servers                192.168.20.1
timed.window                 0s
1. 確認ntp有enable。
2. 確認ntp protocol是ntp。
3. 指定ntp server ip，我這邊是指DC IP。
設定完之後，client即可以正常存取CIFS Share。

如何安裝VMware ESXi 4.1

基本上如果是現在才要佈署or進行POC測試VMware vSphere 4的話，都會安裝ESXi 4.1版本，之前的ESX 4.1目前已經end of life，以後的版本也都會統一稱為ESXi。

至於ESXi 4.1的取的可以至VMware官網下載，或者是透過SI取的，目前最新的版本是"ESXi 4.1 Installable Update 1"，以下我會利用一台Lenovo T410(8G RAM)，安裝完VMware Workstation，然後再把ESXi 4.1安裝Guest OS裏，其中在ESXi Guest OS的網路配置，我選擇是Host-Only，只讓本機與Guest OS相互存取即可，以下是安裝畫面介紹：

1.透過Guest OS掛載ISO檔開機後，即會出現下列選項，請選擇"ESXi Installer"。

2.硬體偵測沒問題，即會載入相關核心檔案。

3. 提醒使用者安裝ESXi的硬體必須符合VMware相容性，直接按Install，進行安裝。

4. 煩人的使用者授權條文，請按F11繼續安裝。

5. 這邊請選擇實際的安裝ESXi的硬碟位置，ESXi其實就是一個修改過後的Linux Kernal版本。

6.按F11確認安裝，ESXi在安裝過程，會把選擇安裝的硬碟，全部格式掉，以完成安裝作業。

7. 安裝過程。

8.提示安裝完成後，請把安裝ISO檔或者是光碟片取出，並且需要重新開機，如果要管理ESXㄛ主機l可透過vSphere Client來進行後續管理。

9. 以下開完機後的登入畫面，我們可以按下F2來進入到ESXi的Local Console管理界面。

大部分我都是利用VNC來遠端管理主機，不過有時候還是會利用VMware vSphere Client

的Console來管理主機，不過碰到安裝完Windows 2008 R2 Guest OS，之後再安裝VMware Tools，最後利用Console去管理Server時，會出現滑鼠在Guest OS裏，有卡卡的現象，所以為了要解決這個問題，必須要更換Guest OS裏的顯卡驅動程式，才能有效解決這個問題，以下是安裝步驟：

1. 預設安裝完VMware Tools後，所抓到的是"標準VGA繪圖卡"。

2. 請到系統\裝置管理員裏，手動把顯示卡的驅動程式智換成"wddm_video"這一個驅動程式，路徑在C:\Program Files\Common Files\VMware\Drivers\wddm_video。

3.  安裝完成之後，即會更新成VMware SVGA 3D這一個顯卡，然後重新開機，這樣就不會在利用Console管理Windows 2008 R2 Guest OS時，會出現滑鼠有卡卡的現象。

如何安裝Gluster，以CentOS為例

首先在安裝Gluster前，請先至官網review一下(Checking Minimum Requirements)，安裝的最小需求，其中除了要安裝的一些必要套件以外，在File System Requirements部分，建議是採用EXT4，所以Linux kernel版本要高於2.6.31 or CentOS版本要高於5.4才支援，不過因為CentOS 5.6目前已經正式announce，所以可以直接用此一版本安裝即可，而在安裝CentOS 5.6時，因為預設的anaconda安裝程式並不會啟動ext4，所以在格式化硬碟，也沒有ext4選項可以選取，這部份請在一開始安裝畫面時，下linux ext4即可利用ext4來格式化硬碟。

請到官網把所需的RPM下載回來，以下是以RPM安裝Gluster範例：

1. 安裝glusterfs-core-3.2.0-1.x86_64.rpm

 2. 安裝glusterfs-fuse-3.2.0-1.x86_64.rpm

3.安裝glusterfs-geo-replication-3.2.0-1.x86_64.rpm時，系統會出現以下錯誤訊息，說明缺少python–ctypes與rsync這兩個套件。

4. 這部份請至rsync: http://packages.sw.be/rsync/rsync-3.0.7-1.el5.rfx.x86_64.rpm與python–ctypes: http://download.fedora.redhat.com/pub/epel/5/x86_64/python-ctypes-1.0.2-2.el5.x86_64.rpm去把下載回來安裝。

5. 重新安裝glusterfs-geo-replication-3.2.0-1.x86_64.rpm

6. 利用/usr/sbin/glusterfs -V，檢查一下安裝後的版本。

以上就安裝完Gluster，夠簡單吧～

GlusterFS叢集分散式檔案系統簡介

會開始研究這套GlusterFS，主要是因為自己在管理企業內部儲存架構時碰到一Bottleneck，而這些Bottleneck原因主要來自如下：

1. 企業的資料量幾乎都是呈線性成長，如果你的企業每天是以1T的空間來成長，那會是一件
很恐怖的事。

2. 企業對於儲存設備效能要求很高，例如是Throughput、 IOPS、Response time等。 

3. 採購儲存設備預算有限，不是每個企業都買得起EMC、NetApp儲存設備，雖然這兩種設備我都用過，但要說服老闆一下子掏出幾百萬去買上述設備，的確難度還滿高的，除非你可以確保採購這些設備，可以帶給你的企業有更高的獲利，類似：Apple iCloud後端是使用EMC的Isilon，其容量高達12PB。

 而GlusterFS剛好有幾項特點，可以match上述需求，所以可以參考如下：

1. 它是Open Source，所以它不用錢，除非你需要它的原廠技術支援服務 or 購買Gluster Virtual Storage Appliances等才需要付費。

2. Gluster是file-based scale-out NAS platform，所謂scale-out的意思，代表它可以平行擴充，它的最大特色就是more units = more capacity, more CPU, and more I/O，所以當你建置的node數量越多，其Disk的capacity與Network performance都會呈線性成長，據我所知Dell的EqualLogicPS Series算是類似概念的Storage產品。

3. Gluster是Software Only，所以他可以安裝在Linux-ike平台上，RHEL、CentOS、Ubuntu、Debian上，不過目前並不支援Windows平台。

4. 除了提供source code、RPM安裝以外，還提供Virtual Storage Appliance(VMware、Xen、KVM)、Storage Software Appliance(ISO檔)等方式配置。 

5. 支援三種Client連接方式，例如：Samba、NFS、Native Client。

6. 由於擁有Scale-out的特性，所以它可以規劃在Public and Private Cloud Environments裏。

7. 由於是採分散式架構，所以可以建立n個node，然後透過Distributed Replicated Volumes功能，來將多個node，組成類似RAID 1功能，這樣不管哪一個node掛掉，資料都不會遺失，因為每個node都保有一份完整資料，所以可以符合企業high-reliability需求。

   

vCenter無法import machine問題

最近在測試vCenter import machine功能時，vCenter卻出現以下
A fatal error occurred. The reason for this might be a network connection failure.The wizard will close
now.Please check your network connection and try again的錯誤訊息：

檢查了一下本機和vCenter的網路連線都很正常，不太可能是網路的問題，上網到VMware Communities查了一下，同樣也有人遇到類似的問題，有人提出的解法是重新restart VMware vCenter Converter Integrated Server和VMware vCenter Converter Integrated Worker這兩個的Service，然後再重新用vSphere Client連線到vCenter以後就可以恢復正常，不過我比較暴力，我是直接重新restart vCenter主機，反正做完Windows Update，剛好要重新開機。