另一個Owncloud中文亂碼問題，坦白說應該是另一個IE中文亂碼問題。原因瀏覽器下載檔案時檔名是參照伺服器送出的header('Content-Disposition: attachment; filename=)這個標頭，而IE在這裡的檔名竟然不支援utf-8而且到了IE9都還沒修正。為了接濟這些可憐的IE只好修改 apps/files/download.php如下
(owncloud 4.5.6版已避開了這個錯誤，不需要進行以下修改)
星期六, 12月 22, 2012
星期三, 12月 19, 2012
Owncloud中文目錄包裹下載
Owncloud提供私有雲端儲存環境的自由軟體解決方案，目前4.5版中文支援已經很完整，但是早期ZIP壓縮檔內的檔名不支援utf-8，所以使用ZIP格式下載整個目錄或多個檔案時大部分解縮軟體無法正確處理utf-8編碼的檔名，造成檔案目錄有中文亂碼問題。修改lib/files.php如下，可以將壓縮檔中的檔名改為以big-5編碼。
星期五, 11月 09, 2012
xenserver SR 救援實錄
我xencenter裡有一個NFS類型的storage repository，因為空間快滿了，就調大了它空間，空間調完後把相關的VM通通關一關，想說順便把NFS SERVER重開一下吧！.......
沒想到重開之後悲劇就發生了，SR有錯誤，後來才知道是因為漏關了一個VM，想說應該不難處理吧，最多VM不正常關機做一下磁碟檢查就可以修復了。
因為自覺問題不大，於是想了一個走捷徑的方法——直接到 XENSERVER手動卸載再重新掛載NFS分享，再到SR重新掃瞄，果然恢復——沒有錯誤了。
再靠近一點看，什麼，VDI全部消失了，再重新掃瞄——當然還是沒有，檢查一下是不是掛載點有問題——果然手動掛載後多了一層SR的UUID，應該可以改回來吧！
還是不要亂玩好了，用XENCENTER裡的DETACH再REATACH應該就會回來吧，果然VDI沒有棄我而去，全部再次出現。
可是、可是，全部的VDI都只有大小，沒有NAME-LABEL、也不知道所屬的VM是誰，一共20幾個VM，每個VM2個VDI，再乘上4倍的SNAPSHOT，天啊！100多個VDI要怎麼幫它們配對。
呆了半個小時已經晚上11:00了，打起精神做好熬通霄的心裡準備，先GOOGLE看看吧！當然有人遇過，但是只找到一個解法，他因為平常有做META DATA的備分，就把XML格式的META DATA打開，一筆一筆找UID，一個一個對應回去，可是我只有剛上線的時候有做META DATA備分，那時候VM又沒幾個，遇到這種情況根本不用擔心。
凌晨12:00終於下定決心，一個一個VDI打開來看是屬於那個VM，再一個一個掛回去。
1.在XENSERVER裡SR的目錄中，使用 ls -lth依時間排序VDI，從最新的開始做，全部VM做完剩下的VDI就是SNAPSHOT，可以暫時不管它。
2.複製最新VDI檔的主名檔，這也是VDI的UUID，使用xe vdi-param-set name-label=tmp_disk uuid=剛剛複製的主檔名，這時VDI就有了臨時的名稱。
3.在XENCENTER中用唯讀方式隨便掛上一台已經開機的VM。
4.用盡全力尋找蛛絲馬跡，判斷這個VDI屬於那個VM。
5.在XENCENTER中修改為正確的名稱。
6.VDI從臨時VM卸下，掛到正確的VM。
弄了一個晚上總算趕在凌晨5:00多天亮前都掛上去，逃過上班被罵的命運。
<<<<<< 一段小插曲 >>>>>>>
WIN SERVER 2008以後的開機碟一定要用唯讀掛載，不然開機區會被改掉，掛到正確的VM也不能開機，修正方式為，使用安裝光碟開機，進入主控台修復模式，CD C:\WINDOWS\STSTEM32 執行，以下三個指令，就可以修復。
bcdedit /set {default} osdevice boot
bcdedit /
bcdedit /set {default} detecthal 1
>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 判斷VDI是那個VM的，真的非常困難 >>>>>>>>>>
判斷VDI是那個VM的真的非常困難，而且大多數的VM都是開給別人用的，不是自己在用，我又是系統碟、資料碟分開建的分式，系統碟還好，大不了進REGISTERY查電腦名稱，一定查的出來；資料碟通常更難判斷。後來用的最多也最也最快的方式是——從磁區大小和剩餘空間來判斷，可是又怎麼可能記得每個VM磁區的大小和剩餘空間呢？這要得力於我之前因為覺得VM數量實在愈來愈多，就導入了OCS INVENTORY——開源的資產管理軟體，來管理，這次真的幫了大忙。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 避免再次發生 >>>>>>>>>>>>>>>>>>>>>
什麼這種慘劇一次還不夠，還會再發生，建議在XENSERVER執行 xe vbd-list param=all is-a-snapshot=false > vdi-list.txt ，再COPY到自己電腦存檔有備無患。其實XENSERVER使用UUID來描述物件，強迫使用者用系統指令或介面操作物件，避免使用者直接對檔案進行操作，應該是比較先進，可以減少人為錯誤的操作方式，但是一旦手殘亂弄，弄出問題卻也讓除錯變得比較困難，那種方式比較好？只能說各有優缺點吧！畢竟使用者的選擇其實不多，用久了就知道地雷在那裡，就可以盡量發揮優點避開缺點。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
沒想到重開之後悲劇就發生了，SR有錯誤，後來才知道是因為漏關了一個VM，想說應該不難處理吧，最多VM不正常關機做一下磁碟檢查就可以修復了。
因為自覺問題不大，於是想了一個走捷徑的方法——直接到 XENSERVER手動卸載再重新掛載NFS分享，再到SR重新掃瞄，果然恢復——沒有錯誤了。
再靠近一點看，什麼，VDI全部消失了，再重新掃瞄——當然還是沒有，檢查一下是不是掛載點有問題——果然手動掛載後多了一層SR的UUID，應該可以改回來吧！
還是不要亂玩好了，用XENCENTER裡的DETACH再REATACH應該就會回來吧，果然VDI沒有棄我而去，全部再次出現。
可是、可是，全部的VDI都只有大小，沒有NAME-LABEL、也不知道所屬的VM是誰，一共20幾個VM，每個VM2個VDI，再乘上4倍的SNAPSHOT，天啊！100多個VDI要怎麼幫它們配對。
呆了半個小時已經晚上11:00了，打起精神做好熬通霄的心裡準備，先GOOGLE看看吧！當然有人遇過，但是只找到一個解法，他因為平常有做META DATA的備分，就把XML格式的META DATA打開，一筆一筆找UID，一個一個對應回去，可是我只有剛上線的時候有做META DATA備分，那時候VM又沒幾個，遇到這種情況根本不用擔心。
凌晨12:00終於下定決心，一個一個VDI打開來看是屬於那個VM，再一個一個掛回去。
1.在XENSERVER裡SR的目錄中，使用 ls -lth依時間排序VDI，從最新的開始做，全部VM做完剩下的VDI就是SNAPSHOT，可以暫時不管它。
2.複製最新VDI檔的主名檔，這也是VDI的UUID，使用xe vdi-param-set name-label=tmp_disk uuid=剛剛複製的主檔名，這時VDI就有了臨時的名稱。
3.在XENCENTER中用唯讀方式隨便掛上一台已經開機的VM。
4.用盡全力尋找蛛絲馬跡，判斷這個VDI屬於那個VM。
5.在XENCENTER中修改為正確的名稱。
6.VDI從臨時VM卸下，掛到正確的VM。
弄了一個晚上總算趕在凌晨5:00多天亮前都掛上去，逃過上班被罵的命運。
<<<<<< 一段小插曲 >>>>>>>
WIN SERVER 2008以後的開機碟一定要用唯讀掛載，不然開機區會被改掉，掛到正確的VM也不能開機，修正方式為，使用安裝光碟開機，進入主控台修復模式，CD C:\WINDOWS\STSTEM32 執行，以下三個指令，就可以修復。
bcdedit /set {default} osdevice boot
bcdedit /
bcdedit /set {default} detecthal 1
>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 判斷VDI是那個VM的，真的非常困難 >>>>>>>>>>
判斷VDI是那個VM的真的非常困難，而且大多數的VM都是開給別人用的，不是自己在用，我又是系統碟、資料碟分開建的分式，系統碟還好，大不了進REGISTERY查電腦名稱，一定查的出來；資料碟通常更難判斷。後來用的最多也最也最快的方式是——從磁區大小和剩餘空間來判斷，可是又怎麼可能記得每個VM磁區的大小和剩餘空間呢？這要得力於我之前因為覺得VM數量實在愈來愈多，就導入了OCS INVENTORY——開源的資產管理軟體，來管理，這次真的幫了大忙。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<< 避免再次發生 >>>>>>>>>>>>>>>>>>>>>
什麼這種慘劇一次還不夠，還會再發生，建議在XENSERVER執行 xe vbd-list param=all is-a-snapshot=false > vdi-list.txt ，再COPY到自己電腦存檔有備無患。其實XENSERVER使用UUID來描述物件，強迫使用者用系統指令或介面操作物件，避免使用者直接對檔案進行操作，應該是比較先進，可以減少人為錯誤的操作方式，但是一旦手殘亂弄，弄出問題卻也讓除錯變得比較困難，那種方式比較好？只能說各有優缺點吧！畢竟使用者的選擇其實不多，用久了就知道地雷在那裡，就可以盡量發揮優點避開缺點。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
星期四, 11月 01, 2012
線上擴展ZPOOL容量
zfs作為開放的磁碟陣列系統，當ZPOOL容量不足時當然要很容易擴充容量︰
- 使用一般磁碟而且有空插槽︰
- 關機(視需要)，插入新硬碟
- zpool add pool_name new_disk
- 使用一般磁碟沒有空插槽︰
- zpool offline pool_name disk_name
- 關機(視需要)，更換較大容量新硬碟
- zpool replace pool_name disk_name
- zpool online pool_name disk_name
- 使用可擴展容量的儲存設備
- 在儲存設備上調整加大LUN的容量
- zpool online -e pool_name disk_name
星期二, 10月 30, 2012
zfs檔案系統內建的重複資料消除技術
重複資料消除?
Deduplication 一般常翻為重複資料刪除，總覺得這個翻譯不好，畢竟資料還是在的，沒有資料會因為重複而被刪除，其實刪除改為消除也不完全貼切，曾經想翻為"資料反重複"，但是連自己唸起來都覺得怪，最後還是決定用 "重複資料消除"。
重複資料消除是目前高階儲存設備常見的功能，它運用數學演算法將資料編碼，遇到編碼相同的資料就認為是重複資料，這時就不需要再重複儲存相同資料，只要多一筆資料紀錄就好。
很明顯這樣作的好處是可以節省硬碟空間，某些情況甚至能節省數倍的空間，而且在CPU及記憶體效能充足的情況下，也有可能發揮 "以運算效能換取儲存效能" 的作用，增進儲存效能。
重複資料類別?
重複資料可以依 files(檔案), blocks(區塊)或 bytes為級別作為消除重複資料之單位。
File-level︰依整個檔案為重複資料單位，CPU負擔最小，缺點是當檔案異動時，原本相同的重複檔案就變成不同的檔案，適合用在不會異動的照片檔或影片檔。
Block-level︰適合作為虛擬主機的虛擬磁碟，因為虛擬主機的作業系統大部分檔案都是同樣的只有少數檔案不同。這也是ZFS採用的類別。
Byte-level︰以Byte為單位對於CPU的負擔最大，適合用於郵件伺服器的資料檔。
即時消除或批次消除?
重複資料消除的時間點可以是檔案儲存的同時，或另行排定系統較閒的時間批次作業。ZFS採用的是即時消除的作法。
使用方式?
zfs set dedup=on tank
該不該用，如何取捨?
重複資料消除是以CPU和記憶體的運算效能換取儲存空間和效能的一種技術，如果重複資料不多就會白白浪費許多運算效能。ZFS檔案系統的好處是檔案系統繼承了儲存池的設定後仍然可以針對個別檔案系統設定，因此可以依不同檔案系統的資料特性設定。
zfs set dedup=off tank/home
zfs set dedup=on tank/vm
zfs set dedup=on tank/src
Trust 或 verify?
zfs判別重複資料的預設演算法採用 SHA256，它的碰撞機率(不同資料但是編碼相同的機率)是 2的256次方之1，雖然這個機率很小，但是還是擔心它發生的話，只要付出額外的運算效能就能加以避免。
zfs set dedup=verify tank
選擇演算法
如果啟用驗證(verify)功能，可以搭配比較單的fletcher4演算法以減輕CPU負擔。
zfs set dedup=fletcher4,verify tank
規模和效能
重複資料消除的檔案系統愈大就必需使用愈多記憶體，DDTs (dedup tables) 必需存在記憶體中才會有比較好的效能，如果記憶體不足ZFS系統會將部分table資料壓縮存到 L2ARC，如果壓縮後還是不足才會存到磁碟中。
本文節錄自
https://blogs.oracle.com/bonwick/entry/zfs_dedup
Deduplication 一般常翻為重複資料刪除，總覺得這個翻譯不好，畢竟資料還是在的，沒有資料會因為重複而被刪除，其實刪除改為消除也不完全貼切，曾經想翻為"資料反重複"，但是連自己唸起來都覺得怪，最後還是決定用 "重複資料消除"。
重複資料消除是目前高階儲存設備常見的功能，它運用數學演算法將資料編碼，遇到編碼相同的資料就認為是重複資料，這時就不需要再重複儲存相同資料，只要多一筆資料紀錄就好。
很明顯這樣作的好處是可以節省硬碟空間，某些情況甚至能節省數倍的空間，而且在CPU及記憶體效能充足的情況下，也有可能發揮 "以運算效能換取儲存效能" 的作用，增進儲存效能。
重複資料類別?
重複資料可以依 files(檔案), blocks(區塊)或 bytes為級別作為消除重複資料之單位。
File-level︰依整個檔案為重複資料單位，CPU負擔最小，缺點是當檔案異動時，原本相同的重複檔案就變成不同的檔案，適合用在不會異動的照片檔或影片檔。
Block-level︰適合作為虛擬主機的虛擬磁碟，因為虛擬主機的作業系統大部分檔案都是同樣的只有少數檔案不同。這也是ZFS採用的類別。
Byte-level︰以Byte為單位對於CPU的負擔最大，適合用於郵件伺服器的資料檔。
即時消除或批次消除?
重複資料消除的時間點可以是檔案儲存的同時，或另行排定系統較閒的時間批次作業。ZFS採用的是即時消除的作法。
使用方式?
zfs set dedup=on tank
該不該用，如何取捨?
重複資料消除是以CPU和記憶體的運算效能換取儲存空間和效能的一種技術，如果重複資料不多就會白白浪費許多運算效能。ZFS檔案系統的好處是檔案系統繼承了儲存池的設定後仍然可以針對個別檔案系統設定，因此可以依不同檔案系統的資料特性設定。
zfs set dedup=off tank/home
zfs set dedup=on tank/vm
zfs set dedup=on tank/src
Trust 或 verify?
zfs判別重複資料的預設演算法採用 SHA256，它的碰撞機率(不同資料但是編碼相同的機率)是 2的256次方之1，雖然這個機率很小，但是還是擔心它發生的話，只要付出額外的運算效能就能加以避免。
zfs set dedup=verify tank
選擇演算法
如果啟用驗證(verify)功能，可以搭配比較單的fletcher4演算法以減輕CPU負擔。
zfs set dedup=fletcher4,verify tank
規模和效能
重複資料消除的檔案系統愈大就必需使用愈多記憶體，DDTs (dedup tables) 必需存在記憶體中才會有比較好的效能，如果記憶體不足ZFS系統會將部分table資料壓縮存到 L2ARC，如果壓縮後還是不足才會存到磁碟中。
本文節錄自
https://blogs.oracle.com/bonwick/entry/zfs_dedup
星期三, 8月 15, 2012
星期一, 8月 13, 2012
星期四, 6月 21, 2012
xenserver虛擬機直接使用iscs做為儲存資源
xenserver對於ISCSI儲存來源，預設的做法是使用LVM2管理，type稱為lvmoiscsi。
使用LVM管理當然帶來很大的管理彈性，但是不可避免的會有效能損失。
其實xen也支援直接使用iscsi做為儲存資源，但是只能使用xe命令操作。
1.新增SR
使用LVM管理當然帶來很大的管理彈性，但是不可避免的會有效能損失。
其實xen也支援直接使用iscsi做為儲存資源，但是只能使用xe命令操作。
1.新增SR
xe sr-create name-label=sr_name type=iscsi device-config:target=target_ip device-config:targetIQN=target_iqn shared=true2.新增LUNxe sr-scan uuid=uuid_of_sr3.RESIZE LUNxe vdi-forget uuid=uuid_of_vdi iscsiadm -m node -R xe sr-scan uuid=uuid_of_sr
移除ISCSI SR的步驟1.列出PBDxe sr-param-list uuid=uuid_of_sr (記下所有PBD)2.unplug PBDxe pbd-unplug uuid=uuid_of_pbd (針對上一步的PBD重覆執行)3.移除SRxe sr-destroy uuid=uuid_of_sr 星期三, 5月 16, 2012
Citrix Xenserver 自訂範本
Linux的發行版經常每半年或一年就推出新版本，xencenter內建的範本也就無法跟上最新版本的腳步，如果想裝較新版本的Linux就需要自訂範本。以下以Ubuntu為例
1.複製現有範本再修改
1.複製現有範本再修改
xe vm-clone uuid=old_template_uuid new-name-label=new_template_name
2.修改範本參數
xe template-param-set uuid=new_template_uuid \
other-config:install-repository=http://archive.ubuntu.net/ubuntu \
other-config:debian-release=發行版名稱
發行版名稱為 hardy locid natty 等
install-repository可以設為其它網路連線速度較快的MIRROW站，
URL的網址為dists的上一層 ，如果不設也可以新增VM時再指定。
星期三, 4月 25, 2012
zfs快照遠端差異複製
zfs是昇陽公司所開發的檔案系統，目前屬於Oracle所有。因為昇陽公司在設在時採用了先進的設計和開放的使用權，所以除了昇陽公司自己的Solaris系統(現在也屬於Oracle)外Apple的Mac OS和許多BSD也採用了zfs的檔案系統，Mac OS的時光回朔功能就是建立在zfs的快照功能之上。
zfs的設計的目的除了作為檔案系統外，還可以來拿作為開放的儲存平台。所以zfs 除了快照以外也提供了壓縮、避免重複資料(deduplication)、遠端複製等進階儲存設備才有的功能。
zfs的遠端複製使用send及receive來傳送及接收zfs的快照資料，如果要透過網路來傳送資料必須由使用者自行搭配其它網路工具來完成，zfs本身未內建網路傳送的功能。這樣的設計雖然操作上比較麻煩可是卻比較有彈性，例如，搭配的網路傳送工具大部分的人選擇了ssh而本文選擇為了效能考量選擇nc(netcut)。
zfs的設計的目的除了作為檔案系統外，還可以來拿作為開放的儲存平台。所以zfs 除了快照以外也提供了壓縮、避免重複資料(deduplication)、遠端複製等進階儲存設備才有的功能。
zfs的遠端複製使用send及receive來傳送及接收zfs的快照資料，如果要透過網路來傳送資料必須由使用者自行搭配其它網路工具來完成，zfs本身未內建網路傳送的功能。這樣的設計雖然操作上比較麻煩可是卻比較有彈性，例如，搭配的網路傳送工具大部分的人選擇了ssh而本文選擇為了效能考量選擇nc(netcut)。
星期三, 2月 15, 2012
openfiler 安裝 Ocsinventory Agent
openfiler是基於rPath所建立的免費網路儲存伺服器(NAS)，而rPath是一種不常見的GNU/Linux系統。rPath安裝套件可以使用conary指令(類似於yum或apt-get)。
Ocsinvnetory是一套開源的資產管理軟體 ，使用時需要在受監控的伺服器上安裝代理程式(agent)
本文應用情境比較特殊，如果您是透過搜尋引擎連結過來本文可能不是您在找的資訊，除非您也想在openfiler安裝perl模組。
Ocsinvnetory是一套開源的資產管理軟體 ，使用時需要在受監控的伺服器上安裝代理程式(agent)
本文應用情境比較特殊，如果您是透過搜尋引擎連結過來本文可能不是您在找的資訊，除非您也想在openfiler安裝perl模組。
星期一, 1月 02, 2012
解決Xenserver中VM 當機連force reboot也失敗的情形
#xe vm-list name-label=VM_NAME 記住VM的UUID
#list_domains |grep vm_uuid 記住第1欄的DOMAIN ID
#list_domains |grep vm_uuid 記住第1欄的DOMAIN ID
訂閱：
文章 (Atom)