Articles of RAID

我应该“运行”一个新的RAID 1对的一个磁盘,以减less类似的失败时间的机会?

我正在设置两个新的4TB硬盘的RAID1arrays。 以前我听说过,在同一时间购买新的相同硬盘的RAID1arrays增加了在相似的时间点失败的机会。 因此,我正在考虑在一段时间内(也许是几个星期)自行使用其中的一个硬盘,以便在短时间内减less这两个故障的可能性。 (未使用的驱动器将保持在抽屉中断开连接) 这似乎是一个合理的方法,或者我更可能只是浪费我的时间?

如何使用CentOS 6监控戴尔PERC H710 Raid控制器的硬盘状态?

我有一台运行CentOS 6的戴尔服务器,使用带Raid 5设置的PERC H710 Raid Controller卡,我想监视Raid Controller后面的硬盘故障/工作状态。 那么我应该可以使用bash脚本来监视硬盘状态,并在发生问题时发送警报邮件。 用于CentOS / Red Hat / Linux的LSI MegaRAID SAS命令工具(关于LSI MegaRAID SAS Linux Tools)不支持PERC H710,而smartctl也不支持。 基于戴尔网站, CentOS不支持此服务器( NX3200 PowerVault ),我无法下载任何Linux程序来监视硬盘。 [root@server ~]# lspci | grep RAID 03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05) [root@server ~]# smartctl -a /dev/sda smartctl 5.43 2012-06-30 […]

将Linux软件RAID 1扩展到RAID 10的最佳方法

mdadm似乎不支持从1级到10级的数组增长。 我在RAID 1中有两个磁盘。我想添加两个新磁盘,并将arrays转换为四个磁盘RAID 10arrays。 我目前的战略: 做好备份。 创build具有两个丢失磁盘的降级4磁盘RAID 10arrays。 rsync the RAID 1 array with the RAID 10 array. 失败并从RAID 1arrays中删除一个磁盘。 将可用磁盘添加到RAID 10arrays并等待重新同步完成。 销毁RAID 1arrays并将最后一个磁盘添加到RAID 10arrays。 问题是在步骤5缺乏冗余。 有没有更好的办法?

LSI CacheCade SSD存储分层效率如何?

LSI提供了CacheCade存储分层技术,允许SSD设备作为读写caching来增强传统RAIDarrays。 其他厂商也采用了类似的技术。 HP SmartArray控制器具有其SmartCache 。 Adaptec拥有MaxCache … 更不用说许多基于软件的加速工具( sTec EnhanceIO , Velobit , FusionIO ioTurbine , Intel CAS , Facebook flashcache ?) 。 从ZFS背景来看,我使用不同types的SSD来处理读取caching(L2ARC)和写入caching(ZIL)的职责。 各自的工作量需要不同的特质; 写入caching的低延迟和耐久性。 高容量的阅读。 由于CacheCade SSD可用于写入和读取caching,因此RAID控制器的板载NVRAM有何用途? 当用作写caching时,CacheCade SSD在写耐久性方面有什么危险? 使用消费者固态硬盘似乎受到鼓励。 写入直接到SSD还是先打到控制器的caching? 读取cachingalgorithm有多智能? 我了解ZFS ARC和L2ARC的function 。 有什么洞察到CacheCade分层过程? 存在什么指标来监控CacheCade设置的有效性? 有没有一种方法来观察caching命中率或百分比 ? 你怎么知道它是否真的有效? 我对LSI解决scheme的意见和反馈感兴趣。 任何警告? 提示?

如何查看软件RAID 1重新同步的状态?

我有两个500 GB的磁盘,昨天我使用软件RAID 1镜像第一个驱动器到第二个。 电脑已经开了30个小时。 两个磁盘都说“重新同步”,但没有进度指示器。 另外,两个磁盘上都有一个小小的黄色感叹号。 我的问题是: 同步需要多长时间才能完成500GB的数据传输? PC有4 GB的RAM和AMD双核4000+ 有没有办法监视同步的状态? 如何检查感叹号的含义?

RAID-5:两个磁盘同时失败?

我们有一台运行CentOS的戴尔PowerEdge T410服务器,其中包含5个希捷酷鱼3 TB SATA磁盘的RAID-5arrays。 昨天系统崩溃(我不知道如何,我没有任何日志)。 在启动RAID控制器BIOS后,我看到5个磁盘中的1个被标记为“丢失”,而3个磁盘被标记为“被降级”。 我强制备份磁盘3,并将磁盘1换成新的硬盘(大小相同)。 BIOS检测到这一点,并开始重build磁盘1 – 但它卡在%1。 纺纱进度指标并没有整夜通宵。 完全冻结。 我在这里有什么select? 除了使用一些专业的数据恢复服务,还有什么方法可以尝试重build吗? 两个硬盘如何能同时失效? 似乎过于巧合。 磁盘1是否有可能失败,结果磁盘3“不同步?” 如果是这样,是否有任何工具可以用来恢复“同步?”

采用硬件RAID的ZFS最佳实践

如果某个人恰好有一些服务器级的硬件需要处理,那么是否build议在基于硬件的RAID1之上运行ZFS? 是否应该closures基于硬件的RAID,然后在mirror或raidz zpool上运行ZFS? 在硬件RAIDfunctionclosures的情况下,基于硬件RAID的SATA2和SAS控制器比非硬件RAID控制器隐藏读取和写入错误的可能性更大或更小? 就非可定制的服务器而言,如果存在硬件RAID控制器实际上成本中立的情况(甚至降低了预build服务器产品的成本,因为它的存在提高了托pipe公司提供互补IPMI的可能性访问),是否应该完全避免? 但是,它应该追求?

RAID控制器同步硬盘旋转?

我正在进入一个新的存储解决scheme市场。 在研究各种规格的同时,我的一位同事表示,一些RAID控制器可以同步硬盘旋转,同时所有驱动器的扇区/块0通过读取头。 我在网上search,但一直没能findcertificate/驳斥这种说法的信息。

BBWC:理论上是一个好主意,但有一个曾经保存过你的数据?

我很熟悉BBWC(电池支持的写入caching)打算做什么 – 以前曾在我的服务器中使用它们,即使是使用良好的UPS。 有不可预料的失败,它不提供保护。 我很好奇它是否真的在实践中提供了实际的好处。 (注意,我特别寻找那些有BBWC的人的反应,并且有崩溃/失败,以及BBWC是否帮助恢复) 更新 经过这里的反馈,我越来越怀疑BBWC是否增加了任何价值。 为了对数据完整性有信心,文件系统必须知道数据何时被提交到非易失性存储器(不一定是磁盘 – 我将回到这一点)。 值得注意的是,当数据被提交到磁盘时,大量的磁盘都是谎言( http://brad.livejournal.com/2116715.html )。 虽然认为禁用磁盘caching可能会使磁盘更加诚实似乎是合理的,但仍然不能保证也是如此。 由于BBWC中的缓冲区很大,因此屏障可能需要将更多的数据提交到磁盘,从而导致写入延迟:一般的build议是在使用非易失性回写高速caching时禁用屏障(并禁用片上caching)磁盘caching)。 然而,这似乎破坏了写入操作的完整性 – 仅仅因为在非易失性存储中维护更多的数据并不意味着它会更加一致。 实际上,逻辑交易之间可以说没有划分,似乎没有机会确保一致性。 如果BBWC在数据input到非易失性存储(而不是承诺磁盘)的时候承认存在障碍,那么它似乎满足数据完整性要求,而不会有性能损失 – 这意味着应该仍然启用障碍。 然而,由于这些设备通常performance出与将数据刷新到物理设备(显着慢于屏障)和广泛的禁用屏障的build议一致的行为,因此它们不能以这种方式performance。 为什么不? 如果操作系统中的I / O被build模为一系列stream,那么当写caching由OSpipe理时,有一定范围可以最小化写屏障的阻塞效应 – 因为在此级别只有逻辑事务(单个stream)需要承诺。 另一方面,不知道哪些数据位构成事务的BBWC将不得不将其整个caching提交到磁盘。 在实践中,内核/文件系统是否真正实现了这一点,需要比我现在想要投资的更多的努力。 磁盘组合告诉fib什么已经承诺和突然失去权力无疑会导致腐败 – 和一个Journalling或日志结构的文件系统,在停电后不能完全fsck不太可能检测到腐败,更不用说了试图修复它。 就故障模式而言,根据我的经验,大多数突然断电都是由于主电源断电(容易通过UPS进行缓解以及pipe理关机)而发生的。 人们把错误的电缆从机架中拉出来意味着数据中心的不良(标签和电缆pipe理)。 有些types的突然掉电事件不会被UPS阻止 – 在PSU或VRM故障时,带有障碍的BBWC将在这里出现故障时提供数据完整性,但是这种事件有多普遍? 在这里没有回应,这是非常罕见的。 当然,将堆栈中的容错移动到更高的位置是比BBWC更昂贵的 – 但是,将服务器作为群集来实现,对于性能和可用性还有很多其他好处。 另一种减轻突然断电影响的方法是实施一个SAN-AoE,使其成为一个实际的主张(我在iSCSI中并没有真正看到这一点),但是成本更高。

大型驱动器的高故障率?

我最近部署了一个5x 1TB硬盘的服务器(我不会提到他们的品牌,但它是最大的一个)。 我最初被警告不要使用大容量硬盘,因为一位朋友告诉我他们的平均无故障时间(MTBF)非常低,而且我会更好地获得更多容量更小的硬盘,因为它们不会因为什么而被“推到极限”技术可以处理。 此后,五个磁盘中的三个失败了。 谢天谢地,我能够在下一张磁盘失败之前更换和重buildarrays,但是让我非常担心。 你怎么看? 我是不是把他们弄糟了? 或者更新/更高容量的磁盘比已经过testing的磁盘更容易失败?