За и против программного обеспечения Parity-RAID (например, RAID5)
Прежде всего это собирается зависеть только от Вашей архитектуры и таможни.
Я, например, монтирую вещи как это под/mnt. Я знаю людей, которые создают высокоуровневые каталоги и людей, которые поместили этот материал в / домой. Все это зависит от того, чем Вы довольны. Нет никакого отличного стандарта на этом больше, архитектура системы изменилась, и у Вас есть переменные представления теперь на вещах, которые раньше были 'евангелием'. Вещи как/usr/local или/opt/share, об/мин или источник... Вы получаете дрейф.
Во-вторых, если Вы перечитаете через свою ссылку по pathname.com, то Вы заметите абзац под / медиа, который указывает
Объяснение
Исторически было много других различных мест, используемых для монтирования removeable медиа, таких как CD-ROM/,/mnt или/mnt/cdrom. Размещение точек монтирования для всех removeable медиа непосредственно в корневом каталоге потенциально привело бы к большому количеству дополнительных каталогов в/. Хотя использование подкаталогов в/mnt как точка монтирования недавно было общим, это конфликтует с традицией значительно старше использования/mnt непосредственно как временная точка монтирования.
Так лично я защищаю/mnt/windows или некоторое повторение этого. Это сохраняет высокоуровневый dir свободным, и просто и интуитивно. То, когда я просматриваю или контролирую систему, это - то, где я ищу, монтируется сразу.
Я предполагаю, что программное обеспечение RAID Linux так же надежно как аппаратная плата RAID без BBU и с включенным кэшированием обратной записи. В конце концов, незафиксированные данные в системе программного обеспечения RAID находятся в кэш-буфере ядра, который является формой обратной записи, кэширующейся без резервного аккумулятора.
Так как каждая аппаратная карта RAID-5, которую я когда-либо использовал, позволяет Вам включать обратную запись, кэширующуюся, не имея BBU, я ожидаю, что программное обеспечение RAID 5 может работать хорошо на людей с определенным уровнем допуска риска.
ObWarStory:
Это сказанное, я лично испытал серьезную потерю данных из-за установки никакого BBU на карте RAID-5, хотя кэширование обратной записи было включено. (Никакой UPS, также. Не вопите на меня, не мой вызов.)
Мой босс позвонил мне в панике, в то время как я был на каникулах, потому что одна из наших производственных систем не возвратится после перебоя в питании. У него закончились вещи попробовать. Я должен был осуществить стороне дороги, вытащить ноутбук, включить WiFi, ограничивающий по моему телефону, ssh в пораженную систему, и фиксируют его, в то время как мое семейство находилось там со мной на стороне дороги, пока я не закончил восстанавливать roached таблицу базы данных от резервного копирования. (Мы были на расстоянии приблизительно в одна миля от проигрывающего приема ячейки в то время.)
Поэтому скажите мне: сколько Вы оплатили бы плату RAID + BBU теперь?
-
1Право - я удалил свой комментарий. Но набег без BBU должен записать через, не так ли? Это, по крайней мере, что делают PERC-контроллеры, когда батарея учится и падает ниже порога. – Nils 04.10.2011, 00:29
-
2Да, без BBU или с мертвым BBU, плата RAID все еще пишет данные. То, что это не делает, помнят то, что было в буфере записи когда сбои питания к серверу. Так как RAID зависит от непротиворечивости среди избыточных битов, это запутывается, когда это становится непоследовательным. Поэтому сбой питания во время записей RAID рискует повреждать что-то на RAID, потому что контроллер вынужден выбрать одну из двух или больше копий данных, не зная, который корректен. – Warren Young 04.10.2011, 01:13
Просто предупредительная надпись: RAID-5/6 операции записи занимают значительное процессорное время, в то время как Ваш массив ухудшается. Если Ваш сервер уже полностью загружается, когда диск приходит к сбою, он может заскочить в пропасть безразличности. Такой проблемы не произойдет с аппаратным RAID-контроллером. Таким образом, я категорически не рекомендовал бы использование программного обеспечения RAID-5/6 на рабочем сервере. Для рабочей станции или слегка загруженного сервера, это в порядке все же.
SW RAID действительно имеет вид отказа - если сервер понижается на полпути через запись, можно получить поврежденную дорожку. RAID-контроллер HW с BBU не все, что дорогой, и он сохранит грязные блоки, пока Вы не сможете перезапустить диски.
BBU в кэше не гарантирует записи в случае сбоя питания (т.е. он не приводит в действие диски). Это приводит в действие кэш в течение нескольких дней, пока Вы не можете перезапустить диски. Затем контроллер сбросит любые грязные буферы к диску.
Некоторые примечания о SW по сравнению с HW СОВЕРШАЮТ РЕЙД 5
Записи на объеме SW RAID-5 могут быть медленными, если запись - посредством кэширования используется с блокированием ввода-вывода, поскольку вызов не возвращается, пока весь ввод-вывод не завершился. RAID-контроллер HW с BBWC может значительно оптимизировать это, таким образом, Вы видите существенно лучшую производительность.
В прошлый раз, когда я смотрел, Вы не могли сделать прямого ввода-вывода (т.е. нулевая копия DMA) на объеме RAID SW. Это, возможно, изменилось и действительно только относится к приложениям как менеджеры базы данных с помощью необработанных разделов.
Современный RAID-контроллер SAS может вытянуть или продвинуть 1GB/sec или больше данных от дискового массива, особенно, если отформатировано с большим (скажите что 256 КБ), размер дорожки. Я даже сравнил более старой Adaptec ASR-2200-е на скоростях, которые указали, что она в значительной степени насыщала оба своих scsi канала в 600MB/sec + в агрегате (10x 15k диски) с очень небольшим количеством загрузки ЦП на хост-машине. Я не уверен, что Вы могли вытащить это из программного обеспечения RAID 5 без большого количества загрузки ЦП если вообще, даже на современной машине. Возможно, Вы могли считать это быстро.
Конфигурация для начальной загрузки от объема RAID HW проста - объем RAID очевиден для O/S.
Низкопроизводительный RAID-контроллер от уровня 1 поставщик, такой как adaptec не является настолько дорогим в розничных розничных ценах и может быть куплен для арахиса от eBay. Но помните, если Вы покупаете подержанный, придерживаетесь, чтобы разделить 1 поставщика на уровни и удостовериться, что Вы знаете модель и проверяете авианеустойчивость драйверов с их веб-сайта.
Править: Из комментария @psusi удостоверьтесь, что Вы не получаете fakeraid (прозрачный SW RAID, скрытый в драйвере), контроллер, но большинство предложений с больших имен (Adaptec, 3Ware или LSI) не является fakeraid единицами. Что-либо, что может взять BBU, не будет fakeraid.
-
1Если сбои питания посреди записи, то Вы получаете дорожку, которая является вне синхронизации, не поврежденной. Из синхронизирующей дорожки просто означает, что четность не актуальна, поэтому когда массив смонтирован, четность должна быть обновлена. Также те контроллеры "набега", которые могут иметься для арахиса, часто fakeraid; у них есть BIOS rom расширения и драйверы окон, которые делают набег в программном обеспечении. – psusi 14.10.2011, 22:54
-
2@psusi - Большинство контроллеров ASR-2200-х, которые я купил несколько лет назад, находилось под 100 долларами США, и они - настоящие RAID-контроллеры HW. Я не думаю, что Adaptec на самом деле делает fakeraid контроллеры вообще. Можно вполне с готовностью получить 4 или 8 портов Adaptec, 3Ware или LSI RAID-контроллеры SAS от eBay за несколько сотен долларов. – ConcernedOfTunbridgeWells 15.10.2011, 22:12
-
3я не назвал бы несколько сотен маркеров для используемого продукта из неизвестного источника "пенсами"; это указывает на больше вдоль строки $50-100 для нового продукта. Устройства в том классе обычно fakeraid. – psusi 17.10.2011, 16:25
-
4@psusi - Вы пытаетесь отклонить аргумент, что я никогда не делал; я никогда не использовал слово 'пенсы' вообще. Не обращайтесь к соломенным аргументам человека - примеры, которые я использовал, не fakeraid контроллеры. SSD – ConcernedOfTunbridgeWells 18.10.2011, 00:52
Если Вы получили данные в кэше, но не на диске уже и сбоях питания, то данные собираются исчезнуть, и Ваш диск, скорее всего, будет в непоследовательном состоянии. Вероятность этого не очень высока, если Вы не получили систему, это постоянно пишет, но я все еще не хотел бы ставить свои данные по играм вероятности.
Интересное скручивание должно было бы сделать основную файловую систему на RAID5/6, но поместить журнал на обычный диск, таким образом, данные сначала выводятся на обычном диске. Производительность, вероятно, перешла бы к crapper, поскольку Вы будете ограничены скоростью записи единственного диска, но надежность повысилась бы. Таким образом, я предполагаю в ситуации, где Ваша производительность записи не важна, но Ваше чтение, который мог бы работать просто великолепно.
Или Вы могли просто потратить еще 100$ и получить карту с BBU или маленький UPS, и избежать всех этих сложностей в целом ;)
-
1
-
2Это сделало бы это, но в тот момент Вы платите больше, чем достойный контроллер во-первых ;) Кроме того, скорость повышается, но надежность понижается, потому что большая часть SSD умирает очень очень быстро. – Marcin 12.07.2011, 14:55
-
3@Marcin, на чем Вы основываете это? Они, кажется, короче не указали время жизни дизайна, и я имел один больше года и только использовал 5% его циклов записи. – psusi 12.07.2011, 16:51
-
4@MarcinWell, Когда Вы говорите, что надежность, является этим savety или доступность? Я не ожидал, что выпуск моего журнала угрожает полным данным. Он? Так или иначе я планирую поместить ОС и Подкачку на меньшем SSD, из-за шума и энергосберегающих причин. RAID может заснуть тот путь. – user773568 12.07.2011, 18:37
-
5MLC имеют послужной список проблем надежности. Единицы SLC являются намного более надежными, но также и намного более дорогими. Отчет о надежности SSD может быть найден здесь – ConcernedOfTunbridgeWells 18.10.2011, 01:00
Linux mdadm набег программного обеспечения разработан, чтобы быть столь же надежным как аппаратный набег с кэшем с аварийным батарейным питанием. Нет никаких проблем с внезапной потерей питания вне тех, которые также обращаются к внезапным потерям мощности на отдельном диске.
Когда система возвратится после сбоя питания будет ресинхронизирован массив, который в основном означает, что четность повторно вычисляется для соответствия данным, которые были записаны перед сбоем питания. Это занимает время, но действительно, никакое грандиозное предприятие. Ресинхронизировать время может быть значительно уменьшено путем включения поглощенного записью битового массива.
-
1Это звучит немного оптимистичным. Как чистый программный продукт может быть столь же надежным как кэш с аварийным батарейным питанием? – user773568 12.07.2011, 13:32
-
2Там является плохими вещами, которые могут произойти с RAID-массивом, которого не может произойти с отдельным диском. С отдельным диском каждый сектор находится или в старом или в новом состоянии. С, например, RAID-5 более чем 4+1 диск, что, если сектор 42 дисков 1 и 2 находится в старом состоянии и секторе 42 дисков 3, 4 и 5, находится в новом состоянии? Ни старое состояние, ни новое состояние не являются восстанавливаемыми. Я не знаю, принимает ли Linux меры для предотвращения этого, и это - то, о чем вопрос. – Gilles 'SO- stop being evil' 12.07.2011, 14:23
-
3
-
4@Gilles Вы только что вновь заявили о том же случае как отдельный диск. Некоторые секторы находятся в старом состоянии, и некоторые находятся в новом состоянии. Это не имеет значения, какой диск они идут. Файловые системы имеют дело с неполными записями во время катастрофического отказа с журналом. – psusi 12.07.2011, 16:48
-
5@psusi: с отдельным диском каждый сектор находится или в новом состоянии или в старом состоянии. С несколькими дисками, если драйвер использует наивный подход перезаписи сектора на каждом диске, не храня информацию в другом месте, сектор, который был в переходном состоянии (старое состояние на некоторых дисках, новое состояние на других), не может быть восстановлен вообще. Ошибка может возможно быть обнаружена (если Вы удачливы: четность могла соответствовать случайно), но она не может быть исправлена. – Gilles 'SO- stop being evil' 12.07.2011, 17:05
Вот блог, объясняя проблему с RAID5 и как ZFS RAIDZ разрешает его.
Его ключевые пункты:
RAID-5 (и другие данные/схемы проверки четности, такие как RAID-4, RAID-6, ровно-нечетный, и Четность Диагонали строки) никогда вполне, выполнил обещание RAID - и не может - из-за фатального дефекта, известного как дыра записи RAID-5. Каждый раз, когда Вы обновляете данные в дорожке RAID, необходимо также обновить четность, так, чтобы все диски XOR для обнуления - случилось так, что уравнение, которое позволяет Вам восстанавливать данные, когда диск перестал работать. Проблема состоит в том, что нет никакого способа обновить два или больше диска атомарно, таким образом, дорожки RAID могут стать поврежденными во время катастрофического отказа или перебоя в питании.
и
RAID-Z является данными/схемой проверки четности как RAID-5, но он использует динамическую ширину дорожки. Каждый блок является своей собственной дорожкой RAID-Z, независимо от blocksize. Это означает, что каждая запись RAID-Z является записью полной дорожки. Это, в сочетании с копией на записи транзакционная семантика ZFS, полностью устраняет дыру записи RAID.