超碰人人人人人,色婷婷综合久久久久中文一区二区,国产-第1页-浮力影院,欧美老妇另类久久久久久

騰訊云在這次事件中的結(jié)論表述為因受所在物理硬盤固件版本Bug導致的靜默錯誤，文件系統(tǒng)元數(shù)據(jù)損壞：

根據(jù)這個表述，故障應出現(xiàn)在硬盤固件故障導致的文件系統(tǒng)元數(shù)據(jù)損壞。這其中，涉及具備因果關(guān)系的三個知識點：

硬盤固件故障—>文件系統(tǒng)元數(shù)據(jù)損壞—>文件損壞。

在此大致畫一下騰訊云可能用到的存儲架構(gòu)方案。

帶*號的是不一定存在的存儲鏈。事實上，這個邏輯肯定不準確，比如有些環(huán)節(jié)精減或不需要，有些環(huán)節(jié)有更詳細的設(shè)計等。但是不是和真實場景一致不重要，重要的是，問題如果出現(xiàn)，總會出現(xiàn)在我列出的項或我沒列出的項中(廢話)，這些項是相互關(guān)聯(lián)的。

我們再重復一下現(xiàn)象：硬盤固件故障(層1故障)導致的文件系統(tǒng)元數(shù)據(jù)損壞，從而導致部分文件校驗出錯，導致文件損壞。針對現(xiàn)象，努力從上述10個環(huán)節(jié)匹配，每一層會有可能出錯，導致上述故障嗎：

一、 第1層：存儲介質(zhì)

以硬盤為例，每個構(gòu)成數(shù)據(jù)的最小單位扇區(qū)都會有嚴格的校驗，包括扇區(qū)頭部的CRC校驗以及地址標識校驗。理論上，如果層1的數(shù)據(jù)出現(xiàn)磁力失真(或閃存狀態(tài)丟失)等比特出錯，其頭部校驗不匹配時，介質(zhì)控制器就會向上層反饋錯誤(一般表現(xiàn)為壞扇區(qū))，上層會啟動修正模式進行修正。

當然也有例外，比如硬盤內(nèi)部程序出錯，根本不按上述原則執(zhí)行，忽略校驗值的情況下，任何對數(shù)據(jù)的篡改都是可以的?？梢员憩F(xiàn)為騰訊所說的靜默損壞（即層1在合理的邏輯里偷梁換柱)。這種情況，基本大帽子就能扣在硬盤固件BUG這上面了，但硬盤固件這種BUG是致命的，等同于我們存進銀行的錢不知什么原因變多或變少，沒有硬盤廠商站出來承認，也沒有緊急發(fā)布BUG修復固件，完全歸因于硬盤固件，可能偏激了些(也可能事件背后有固件BUG的原因，那也應該是添油加醋型的)。

二、 第2層：RAID

RAID自身有冗余算法，可實現(xiàn)在部分介質(zhì)（硬盤）損壞后，由其他成員及算法控制來接管損壞硬盤的數(shù)據(jù)服務，保證上層業(yè)務不中斷，不出故障。但RAID也并非完全可靠。

一種錯誤是軟RAID中的寫漏洞(write hole)，如果是軟RAID，這無法避免，可能導致騰訊本次事故。但軟RAID是玩具產(chǎn)品，自然騰訊是不會用這種方案的。

還有可能的錯誤是buffer dirty，當緩沖數(shù)據(jù)掉電清空，或有意無意損壞后，會導致數(shù)據(jù)出現(xiàn)本例的表現(xiàn)錯誤。但這個原因可以很容易推到控制器BUG上面，騰訊沒提及這個原因，或者是他們沒找到病根，或者的確和這個無關(guān)。

還有最可能的錯誤是RAID中超過冗余數(shù)量的磁盤損壞。比如RAID5只支持一塊盤損壞，但現(xiàn)實中出現(xiàn)了：

情形1：同時2塊或以上硬盤損壞

情形2：1塊損壞后未及時重建，第2塊又損壞

情形2出現(xiàn)的可能性非常大，幾乎IT類公司沒有不濕鞋的，只是數(shù)據(jù)或不重要，或未千萬公眾效應。本次騰訊事故，情形2導致的數(shù)據(jù)災難，不是沒有可能。想象一下，以RAID5為例，若底層RAID有硬盤壞，管理人員沒及時跟進重建，希捷負載加重后，其他硬盤壞，是非常正常的事情。更有一種情況，與硬盤固件有關(guān)，就是硬盤已經(jīng)有壞道了，但并未碰觸到壞道區(qū)，這時表現(xiàn)一切完好，一旦重建，就會導致RAID崩潰。

一般而言，工程師的修復方法就是強制上線，讓帶病的硬盤強行工作，也可能不懂的工程師隨便上線了舊掉線的硬盤，這時，就會表現(xiàn)為大多數(shù)數(shù)據(jù)可訪問，但部分數(shù)據(jù)（尤其較新）出現(xiàn)損壞，與騰訊公開的表現(xiàn)相似。

三、 第3層：虛擬卷層

虛擬卷往往用在大的云存儲中心，簡單地舉例來說，如果由1000個硬盤構(gòu)成的一個存儲系統(tǒng)，再按8硬盤一組的方式進行存儲劃分，會有很多問題(高故障、空間利用不集中等)。為此，很多廠商開始提及虛擬化存儲，方法各有不同，但基本就是存儲池化---意思是所有可用的空間在確保案例的前提下，匯總到一個統(tǒng)一管理的“池”中，再根據(jù)需求靈活分配虛擬磁盤。

一種方法是把所有硬盤放到池子里，再切塊組RAID，再組個存儲池，再劃分虛擬卷。華為把這個技術(shù)稱為RAID2.0，其實HP EVA、3PAR也都按這個技術(shù)在實現(xiàn)(網(wǎng)絡(luò)上的主流資料描述HP EVA的算法均有誤)，DELL康貝(Compellent)都是這樣實現(xiàn)。這種思路硬盤如果足夠多，在使用前期安全性很好（有足夠多的混在隊伍中的替補，可以快速替換故障數(shù)據(jù)塊），但后期隨著損壞硬盤數(shù)量的增加(尤其越是自動替換，管理人員就越松懈)，故障率就會增加。

舉個HP-EVA的例子，一組存儲144個硬盤，在崩潰臨界點，先后有近40個硬盤報故障。故障的根源其實來源于硬盤預警失效、控制器又完全呆傻的BUG。40個故障硬盤遠遠超過可以激活系統(tǒng)的故障數(shù)量，就導致所有部署在本存儲上的數(shù)據(jù)全部下線。一般HP官方的最高解決辦法(美國的一線)，就是用指令強行激活存儲，讓存儲自己計算缺失數(shù)據(jù)，當數(shù)據(jù)的確落到壞道處無法校驗生成時，就會用舊狀態(tài)數(shù)據(jù)(EVA快速重建時會可能保留某些數(shù)據(jù)塊的舊狀態(tài))或全0代替。這樣，就會導致上層文件系統(tǒng)故障。文件系統(tǒng)故障就是表現(xiàn)為元文件故障，否則元文件沒壞，文件系統(tǒng)就不會壞，頂多表現(xiàn)為文件內(nèi)容不正確。

騰訊本次的事故也有這個可能。

另一種方法是把所有硬盤按xD+yP的方式構(gòu)建RAID(如8個硬盤的數(shù)據(jù)，配一個硬盤的校驗)，再把所有的RAID放到池里，再從池中劃分虛擬磁盤。IBM DS8000、HP X20000、DELL EqualLogic都用這個方案。這是非常垃圾的方案，IBM和HP的上述兩類存儲都是上千萬一套的產(chǎn)品，但故障風險極大，我們的國企，政府常用，也常出問題，只是沒人知道。故障主要來源于不斷放大的RAID風險，每一組RAID假設(shè)有1/10000的概率損壞(如第2層中的情形2)，如果1000個硬盤，有100組，損壞概率就放大了100倍，想想也可怕。但騰訊本次事故不太可能用IBM、HP、EMC的存儲，因為太貴了，又不是存自己的核心數(shù)據(jù)?？赡苡行S商或騰訊自己用軟件定義的方式搭建本類存儲，損壞的可能也就如同第2層中的情形2。

四、 第4層：虛擬卷快照

快照是對某個數(shù)據(jù)集某個時間段的差異數(shù)據(jù)組合。快照集疊加到其父集上，就可以表現(xiàn)為最新的數(shù)據(jù)副本。集中在快照上的故障往往因人為發(fā)生，比如以為某個快照副本已經(jīng)失效，刪除后發(fā)現(xiàn)刪錯了；比如在回到某個快照狀態(tài)時選錯了，再也退不回去等等。

如果照著騰訊本次的事故，至少有一種可能會導致故障現(xiàn)象的發(fā)生：管理人員因故(遷移、維護等原因)對數(shù)據(jù)做了快照，在清理臨時數(shù)據(jù)時不小心刪除了快照副本，緊急搶救后，快照數(shù)據(jù)救回來有部分損壞，快照合并后表現(xiàn)為部分數(shù)據(jù)損壞。當然，這個可能性不大，騰訊本次事故中沒有選擇數(shù)據(jù)恢復專業(yè)公司介入(只要有選擇數(shù)據(jù)恢復方案，北亞不會不知道)，應該不會有這種實施可能。

五、 第5層：大數(shù)據(jù)或云存儲層

出問題的騰訊云是基于虛擬化技術(shù)構(gòu)建的，涉及虛擬化，就一定會設(shè)計資源的集中分配。涉及數(shù)據(jù)部分，單一或獨立存儲很難響應IO的不確定性峰谷請求，所以，騰訊應該會設(shè)計Hadoop之類的平臺來提供數(shù)據(jù)資源分配。

在大數(shù)據(jù)平臺的設(shè)計邏輯里，數(shù)據(jù)IO資源會以可能平均地分配在所有節(jié)點中。而管理他們的元數(shù)據(jù)或集中或分布式。邏輯上，用戶數(shù)據(jù)與元數(shù)據(jù)是獨立的。

但現(xiàn)在的大數(shù)據(jù)平臺往往是基于傳統(tǒng)單機文件系統(tǒng)為載體進行架構(gòu)。單機文件系統(tǒng)的操作手段、命令并未廢止。所以，在一些情況下，大數(shù)據(jù)平臺出故障，可能會導致騰訊類似的數(shù)據(jù)災難。

僅僅是舉幾個想象的例子。

如果維護人員不小心刪除大數(shù)據(jù)平臺下一層文件系統(tǒng)上的某些數(shù)據(jù)塊，大數(shù)據(jù)平臺的冗余也無法還原某個數(shù)據(jù)塊的話，就會表現(xiàn)某個用戶的虛擬機數(shù)據(jù)缺失。

如果維護人員沒及時維護節(jié)點，某些節(jié)點損壞，超過了冗余級別，也會導致某個用戶的虛擬機數(shù)據(jù)缺失（也有可能用VMware vSAN之類的技術(shù)，同樣這種可能也存在）。

騰訊的事故是否如此，不得而知。

六、 第6層：虛擬化文件系統(tǒng)

VMware vsphere、Xen、KVM或Hyper-V是專門的虛擬化系統(tǒng)平臺。這些虛擬化平臺，為了實現(xiàn)塊級別的同時訪問，且適應虛擬機的大塊分配原則，有時要設(shè)計自己的文件系統(tǒng)，最為典型的是VMware的VMFS。

以VMFS為例，對VMFS引發(fā)本次事故表現(xiàn)的可能舉舉例子，如下：

1、VMFS是典型的共享塊設(shè)備文件系統(tǒng)，是基于每臺VMWARE服務器的約定，如果接入存儲網(wǎng)絡(luò)的是普通單機，他可不管是不是共享，有時就會獨占存儲設(shè)備，導致VMFS的破壞。強行修復后，就會出現(xiàn)某臺虛擬機數(shù)據(jù)損壞的情況。

2、VMFS管理時不小心刪除數(shù)據(jù)，或擴容、縮容，也會導致VMFS文件系統(tǒng)損壞，修復后，可能出現(xiàn)某臺虛擬機數(shù)據(jù)損壞的情況。

七、 第7~8層：虛擬磁盤文件與快照

虛擬機的數(shù)據(jù)載體是虛擬磁盤，往往表現(xiàn)為宿主系統(tǒng)上的一個文件或一個獨立區(qū)域。以文件形式表現(xiàn)的居多，如RAW、VMDK、VHD、VHDX、QCOW2等格式。

這些虛擬磁盤和普通文件表現(xiàn)相同，就會面臨和普通文件一樣的損壞可能。比如上層誤刪除文件、上層格式化、文件截斷、文件遷移時中斷等。這些文件一旦破壞，即使恢復回來，也可能不是100%，就會與騰訊本次數(shù)據(jù)災難的表現(xiàn)相同。

磁盤文件快照與第四層的卷快照原理相似，Hyper-V對其稱為差異磁盤，表述直接明了。快照文件丟失或損壞后，也可能與騰訊本次數(shù)據(jù)災難表現(xiàn)相同。

八、 第9層：虛擬機文件系統(tǒng)

分配給用戶的虛擬機，其硬盤就是前文提到的虛擬磁盤文件，但進入虛擬機后，就等同于物理硬盤。這些硬盤也被正常操作方法分區(qū)、格式化、安裝系統(tǒng)、安裝應用等。不論Windows的NTFS、Linux的Ext4等，文件系統(tǒng)總會可能有突發(fā)性的災難。但本次事幫顯然不屬于此，僅聊聊可能的數(shù)據(jù)風險。

一是來自誤操作。如格式化、刪除數(shù)據(jù)、同名文件覆蓋等。

二是來自系統(tǒng)bug。但bug并非是特別明顯的，有時是需要多方環(huán)境因素催化。舉個例子，在NTFS上打開卷壓縮，存入一個上百GB的文件，文件系統(tǒng)8成會崩潰，連現(xiàn)有文件都可能找不到(在早些年，我做了很多這處條件下的試驗，最終確定的確是系統(tǒng)bug，最近未做實驗，或許Microsoft已修正)。另一個例子，非常常見，在WINDOWS上運行ORACLE數(shù)據(jù)庫，數(shù)據(jù)庫文件的增長粒子設(shè)置過小(比如1M之類)，當數(shù)據(jù)大小到上百G時，不出5年，幾乎肯定會崩潰(數(shù)據(jù)文件大小截為0，或內(nèi)容交串出錯)。

九、 第10層：文件

這一層沒什么好說的，往往是來自于上述幾層的故障，導致文件損壞。除此之外，就謹防勒索病毒吧。

十、 建議

數(shù)據(jù)災難大方向有2個：人為災難和不可抗力災難。能給出的建議大概如下：

1、備份。

備份的重要性毫無疑問，但要講方法，為避免硬件故障，就不能備份在同一個或同一類硬件載體上；為避免自然災害，就要異地備份；為避免備份集過多帶來的管理問題（找數(shù)據(jù)都費勁之類的），應制定良好的備份計劃；為避免同類介質(zhì)受環(huán)境的影響，就應該考慮不同介質(zhì)的方案，如光存儲與磁存儲各自備份；為避免有意或無意破壞，備份集就應該設(shè)不同的存取權(quán)限，不能一把鑰匙開所有門……

2、規(guī)范管理和實施。

很多企業(yè)級數(shù)據(jù)災難往往來自于人為，因為任何一個系統(tǒng)，在涉及維護的時候，都必須工作在無保護狀態(tài)，任何一個不小心都可能導致無法回溯的后果。制定嚴格的維護實施方案、備份計劃、預警機制是非常重要的保障。

3、數(shù)據(jù)取舍。

太老的數(shù)據(jù)就刪了吧，再對數(shù)據(jù)精簡整理，再做詳細的管理計劃。要知道，娶妻越多，頭頂發(fā)綠的機會就越大。