|
||
|
Advance Member
  加入日期: Jan 2003
文章: 334
|
引用:
運氣真的很差... 引用:
老兄，我也不想啊，硬碟就要滿了 我已經打算換代管公司了，有沒有人推薦日本的代管？ 引用:
我越來越覺得 Raid 真的沒有在資料安全上做的很好 可能是投入的資金和規模不夠大吧，Raid5 感覺很脆弱 而這種錯誤也不是換掉有問題的硬碟就可以解決的，還需要整個陣列打掉重做 |
||||||||||
2013-10-10, 11:25 PM
#21
|
|
|
*停權中*
加入日期: Jun 2002 您的住址: 地球
文章: 215
|
之前公司的影音伺服器用的是RAID3的
配上18顆資料硬碟,2顆spare 不過人算不如天算 某天公司天線遭雷擊,六台裡面有四台被打掛... 這該怎麼算? |
||
|
2013-10-11, 02:32 AM
#22
|
|
|
*停權中*
加入日期: Jun 2013
文章: 138
|
引用:
我有說用SSD是為了要增加SERVER的開機速度的嗎  這只是附加的好處吧。 真正的用途是在4K THREAD 存取，SSD快傳統硬碟非常多。 比起用RAID 加速，我覺得不如用SSD安全快速的多咧。 當然SERVER 用的SSD選個可靠耐用的名牌比較好。 |
|
|
2013-10-11, 06:34 AM
#23
|
|
|
*停權中*
加入日期: Mar 2012
文章: 161
|
機器都會壞，密集排程備份+異地同步備援才是唯一的解
|
|
2013-10-11, 06:40 AM
#24
|
|
|
Major Member
 
加入日期: Aug 2001
文章: 211
|
引用:
In my humble opinion... SSD 比硬碟快應該跟 4k thread 啥的無關，那東西只是加速而已，實際上就算沒有什麼 thread 加速，SSD 還是比硬碟快。 主要的差異在 SSD 是 random access 而硬碟需要 seek。
__________________
滿招損 謙受益 |
|
|
2013-10-11, 06:54 AM
#25
|
|
|
*停權中*
加入日期: Jun 2013
文章: 138
|
引用:
4k thread不就是Random access , 我們是在講同一件事吧， 只是thread 應該還有多工multitasking的意思在  |
|
|
2013-10-11, 07:09 AM
#26
|
|
|
Advance Member
加入日期: Feb 2003 您的住址: 台北縣
文章: 381
|
常識就是有 Ctritical Data 就會有 Online Backup (Raid Disk)，有 Online Backup 就必須要 Offline Backup (Tape)。有錢肯砸的，還可作 DR 異地備援。另外 SSD 拿來放資料也是會死很慘，那天 IC 寫掛了連救都救不回。備份就跟保險一樣，有備無患，出事就用得到。
|
|
2013-10-11, 07:23 AM
#27
|
|
|
Senior Member
加入日期: Jun 2001 您的住址: 綠島
文章: 1,369
|
引用:
沒錯~ 把Ram撐大還比較有用...
__________________
武士：看來我不應該來。 紫霞：現在才知道太晚了， 武士：留下點回憶行不行？ 紫霞：我不要回憶，要的話留下你的人。 武士：這樣只是得到我的肉體，並不能得到我的靈魂，我已經有愛人了，我們不會有結果，你讓我走吧。 紫霞：好，我讓你走，不過臨走前你要親我一下。 |
|
|
2013-10-11, 08:39 AM
#28
|
|
|
Power Member
加入日期: Aug 2002
文章: 688
|
Redundant RAID
__________________
性子是拿來磨的,不是拿來使的 |
|
2013-10-11, 09:09 AM
#29
|
|
|
Elite Member
加入日期: May 2002 您的住址: 地球的上面..
文章: 5,854
|
引用:
這4~5年來.. 算是近代RAID f/w會操作一種OAR(RAID Roaming)的行為... 他會因為RAID controller的替換而從VD的metadata進行import的操作... 比方說LSI的RAID f/w(IMR)會預先切入512MB(per PD)左右的tail作為metadata... 假設我替換RoC(如果是IR mode則為有限的64MB)... 通常並不會因為掛了而導致VD全部救不回... 因為OAR將會復原這些操作.. (如果這種基本的競爭條件都做不到, 那些RD全部都要去填海...  ...)但是他有個附加前提.. 1. 最好不要與ODR操作衝突, 因為這是metadata的不一致性情況的可能. 2. 如果先前有做過HSP操作, 也必須要注意!..因為這已經不是原來的metadata.. 我相信很多MIS根本都不會想到要操作copyback這塊來復原metadata, 乖乖就把HSP當成VD的一部分操作(找死嗎?? ..)... 這時HSP是一種revertable的狀態(因為連文件都不想讀, 有簽合約維護就算了. 叫廠商去死(依合約內容而定)..)...,RAID f/w提供哪些RAID mode那根本都是basic functions... 這些設計專屬的RAID ASIC提供差異化的RAID f/w的IP廠商.. 真正的重點在於它們所提供的附加價值... 比方說之前有幾個網友來問我(居多都是對岸的案例..).. 有一個案例, 不過他是新加坡的.. 他的100TB(LSI)系統掛了, VD上的48顆PD全部offline.. RAID f/w已經判斷為foreign狀態... 這不只是著急, 而是快崩潰了.. 既沒有任何合約廠商來協助, 也不可能找提供RAID IP的原廠來幫忙(因為很費時..) 但是他最後的復原操作其實很簡單(良好的文件支持網站可以到intelraid尋找, 這大廠並不吝嗇, LSI的KB在1~2年前已經換掉了, 爆爛一把的. 超難用!).. 1. 判讀h/w log(不是event log, 不一樣的東西), it's very important! 2. 安全性的操作(不會破壞metadata) 3. 如果失敗, 在判讀一次h/w log 4. 確認操作一次init w/o BGI即可復原(風險較高, 通常擺在最後..) 5. PR+CC作下去, 確認可靠性 6. 然後收錢(沒收啦!..我又不幹這行..)... 有些時候只有那幾種步驟... 當然我沒有看過很多案例....  但是有些情況就只有那樣子而已..  ...我不否認有一些特殊情況... 因為實在太特殊... 跟RAID本身幾乎八竿子打不著邊... 此文章於 2013-10-11 10:16 AM 被 vxr 編輯. |
|
|
2013-10-11, 10:06 AM
#30
|
|
