The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Первый стабильный выпуск BTIER, блочного устройства для агре..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Первый стабильный выпуск BTIER, блочного устройства для агре..."  +/
Сообщение от opennews (ok), 27-Май-13, 11:41 
Представлен (http://www.lessfs.com/wordpress/?p=909) первый стабильный релиз проекта BTIER 1.0.0 (http://www.lessfs.com), предназначенного для формирования многоуровневых блочных устройств, состоящих из нескольких разнотипных устройств небольшого размера. Код системы отмечен как стабильный и прошедший тестирование в промышленном использовании, в том числе в достаточно сложных конфигурациях, в которых используются сетевые разделы DRDB и работают приложения Oracle. BTIER оформлен в виде модуля для ядра Linux, который может быть собран для ядер, начиная с выпуска 2.6.32. Изначально проект развивался под именем TIER, но был переименован (http://www.lessfs.com/wordpress/?p=850) в BTIER для того чтобы упростить выборку связанной с проектом информации через поисковые системы. Исходные тексты BTIER распространяется под лицензией GPL.


За счёт оптимального разнесения блоков по дискам и использования техники активного кэширования данных в ОЗУ раздел на базе BTIER позволяет заметно поднять производительность сводного раздела. Например, при тестировании BTIER-раздела, созданного на базе SSD-накопителя STEC Zeus и 5 SAS НЖМД, и экспортируемого через iSCSI (SCST), была продемонстрирована (http://www.lessfs.com/wordpress/?p=850) способность выполнения заметно большего числа операций в секунду, по сравнению с системой кэширования на SSD-накопителях BCache (http://www.opennet.ru/opennews/art.shtml?num=35849).

<center><a href="http://www.lessfs.com/wordpress/wp-content/docimages/btier_m... src="http://www.opennet.ru/opennews/pics_base/0_1369637152.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="BTIER" border=0></a><a href="http://www.lessfs.com/wordpress/wp-content/docimages/bcache_... src="http://www.opennet.ru/opennews/pics_base/0_1369637182.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="BCACHE" border=0></a></center>

Использование BTIER позволяет достигнуть более высокой производительности по сравнению с другими методами ускорения доступа к данным, использующими SSD-накопители, благодаря применению техники кэширования в оперативной памяти, ранее реализованной в RAM-диске EPRD (http://www.opennet.ru/opennews/art.shtml?num=33541). При распределении данных по дискам TIER учитывает статистику доступа к уже размещённым данным, например, принимает во внимание то, когда данные использовались последний раз и как часто они запрашиваются. При наличии разных типов накопителей в пуле, отличающихся скоростными характеристиками, наиболее востребованные данные будут вытеснены на более быстрые накопители, такие как SSD или SAS, а редко используемые данные будут размещены на медленных дисках.


В итоге, BTIER позволяет значительно сэкономить, используя SSD только для действительно востребованных данных, при том, что общая ёмкость всего быстрого хранилища в BTIER составляет сумму из всех подключенных устройств хранения. Например, близкий аналог flashcache (http://www.opennet.ru/opennews/art.shtml?num=26440) может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство. Кроме производительности, от других систем виртуального слияния хранилищ BTIER отличается поддержкой автоматической миграции данных между накопителями и обеспечением "умной" балансировки размещения блоков данных на накопителях в зависимости от характера нагрузки.

URL: http://www.lessfs.com/wordpress/?p=909
Новость: http://www.opennet.ru/opennews/art.shtml?num=37023

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от виндотролль (ok), 27-Май-13, 11:41   +6 +/
Вот это, я понимаю! Не то что всякие там фюжндрайвы и турбобусты (или как там в винде называется кеширование дллок).
Да еще и под GPLv3!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6

2. Сообщение от Аноним (-), 27-Май-13, 11:46   +/
наконец то, что нужно!!!  годнота!!!
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от cmp (??), 27-Май-13, 11:46   –1 +/
Дык линукс же и так кеширует весь обмен с фс в ОЗУ, то есть, хошь ускориться добей оперативы; сервера нагруженные, так ведь там и железо соответстующее, в крайнем случае есть своп, который как раз и можно держать на ссд или сас, если данные в оперативу совсем не лезут, в чем профит?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #15, #16

4. Сообщение от Andrey Mitrofanov (?), 27-Май-13, 11:55   +/
> Да еще и под GPLv3!

Путаешь с lessfs.

btier-1.0.0.tar.gz лежит COPYING =GPLv2, в "документации" лицензия не поминается, в исходнике модуля, в _одном файле из _7_:

* Partly based up-on sbd and the loop driver.
* Redistributable under the terms of the GNU GPL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12

5. Сообщение от Аноним (-), 27-Май-13, 11:56   –1 +/
еще бы совместно с  EPRD  заюзать, будет просто супер!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #25, #65

6. Сообщение от linux must _RIP_ (?), 27-Май-13, 11:57   –13 +/
очередной троль - который не потрудился посмотреть исходники. GPL v2 таки более популярна и она использована.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13, #60

7. Сообщение от Andrey Mitrofanov (?), 27-Май-13, 11:59   +/
> Дык линукс же и так кеширует весь обмен с фс в ОЗУ,
> то есть, хошь ускориться добей оперативы;

Ну, как бы тех, кто пишет и использует БД интересует момент окончания _записи на ...[ммм, как это есть по-русски]... non-volatile носитель.

> в крайнем случае есть своп, который как раз  и можно держать на ссд

:*)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #9, #18

8. Сообщение от Аноним (-), 27-Май-13, 12:02   –1 +/
DRBD
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #23, #24

9. Сообщение от Andrey Mitrofanov (?), 27-Май-13, 12:03   +/
> кто пишет и использует БД интересует момент окончания _записи на

Гм. Поправочка "ФС и БД".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

10. Сообщение от Andrey Mitrofanov (?), 27-Май-13, 12:04   +2 +/
> DRBD

Семнадцать!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

11. Сообщение от Аноним (-), 27-Май-13, 12:07   +/
Аналог технологии FAST (Fully Automated Storage Tiering).
Хорошо.
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от виндотролль (ok), 27-Май-13, 12:12   +1 +/
Пардон, зашел сюда http://www.lessfs.com/wordpress/, увидел GPLv3 и обрадовался... Спасибо.

Да все-равно круто же.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #19

13. Сообщение от виндотролль (ok), 27-Май-13, 12:14   +7 +/
> очередной троль - который не потрудился посмотреть исходники.

Спасибо, что прочитали мой ник. А Вы тире не к месту употребили ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #20

14. Сообщение от Аноним (-), 27-Май-13, 12:15   +1 +/
Зачем? Задачи разные. Никто не мешает сделать EPRD поверх.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

15. Сообщение от Аноним (-), 27-Май-13, 12:18   +3 +/
> если данные в оперативу совсем не лезут

то нужно не городить свопы а разгрузить телегу

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

16. Сообщение от ананим (?), 27-Май-13, 12:20   +/
1. Объединение разнотипных, разноскоростных, разноразмерных (и тд) устройств в одно логическое.
2. Никакой кэшЪ не поможет от синк. Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому. К примеру в оракле (по-мимо транзакций и тд) каждые 3 секунды чекпоинт, скидывает "грязные" блоки на диск.

Зыж
Вопрос по сабжу — как с загрузкой с таких разделов? И когда будет в ванниле?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #26, #66

17. Сообщение от pavlinux (ok), 27-Май-13, 12:22   +/
НоtSwap и Hot Spare надо, в виде утилиты хотя бы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

18. Сообщение от linux must _RIP_ (?), 27-Май-13, 12:23   –3 +/
я бы сказал - на persistent storage. особенно в плане комита транзакций. Поэтому в linux был в свое время (может и даже сейчас) смешной баг у dm_multipath - когда один из каналов более быстрый и более новые транзакции комитились раньше старых, что приводило к неработоспособности барьеров внутри FS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #22

19. Сообщение от ананим (?), 27-Май-13, 12:24   +1 +/
Даже круче — значит можно ожидать в ваниле, то биш "изкаропки".
Не удивлюсь что именно поэтому и гпл2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

20. Сообщение от ананим (?), 27-Май-13, 12:25   +2 +/
Так у него как? Если ворд не подчёркивает, значит правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #31

21. Сообщение от NikolayV81 (?), 27-Май-13, 12:27   –1 +/
Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD, а то определить какие данные потерялись при вылете SSD будет проблематично, хотя вероятнее всего самые нужные ;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #28, #42

22. Сообщение от ананим (?), 27-Май-13, 12:34   +/
Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не предназначены балансировать.
Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
Тоже было (на личном опыте своими глазами видел) и в соляре, а в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался" пропавшим. И все транзакции за это время как в /dev/null ушли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32

23. Сообщение от Аноним (-), 27-Май-13, 12:35   +1 +/
Асфальт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #29

24. Сообщение от Аноним (-), 27-Май-13, 12:43   –1 +/
Distributed Replicated Block Device

для тех кто не понял, это было на "сетевые разделы DRDB"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

25. Сообщение от Аноним (-), 27-Май-13, 12:52   +/
> еще бы совместно с  EPRD  заюзать, будет просто супер!

А разве EPRD не блочное устройство?
Или BTIER блочные устройства не поддерживает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

26. Сообщение от pavlinux (ok), 27-Май-13, 12:53   +/
> Если процессу нужно точно знать, что данные на диске, то будет иовэйт по-любому.

Процессу можно сказать, что данные есть, "- а где  и как - тя нипёт!".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #36, #61

27. Сообщение от pavlinux (ok), 27-Май-13, 12:57   +/
> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
> а то определить какие данные потерялись при вылете SSD будет проблематично,
> хотя вероятнее всего самые нужные ;)

можно замутить RAID 1 из BTIER дисков =-o

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #43

28. Сообщение от Аноним (-), 27-Май-13, 12:57   +/
> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
> а то определить какие данные потерялись при вылете SSD будет проблематично,
> хотя вероятнее всего самые нужные ;)

Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от вероятного "протирания до дырки" грубо в N раз, а применяя на них N x RAID0 мы увеличиваем ресурс в N раз, тем самым снижая эту вероятность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #34

29. Сообщение от Нанобот (?), 27-Май-13, 12:58   +1 +/
не согласен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #45

30. Сообщение от Анонимко (?), 27-Май-13, 13:07   –6 +/
Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #47

31. Сообщение от linux must _RIP_ (?), 27-Май-13, 13:17   –8 +/
хреновый из тебя наблюдатель ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #35

32. Сообщение от linux must _RIP_ (?), 27-Май-13, 13:18   –4 +/
> Дык у всех мультипасов такой "баг". Они как бэ нагрузку и не
> предназначены балансировать.
> Пихание разнотипных носителей по такой схеме сродни забиванию гвоздей буратинами.
> Тоже было (на личном опыте своими глазами видел) и в соляре, а
> в винде (2000) вообще отвалившийся девайс только минут через 20 "обнаруживался"
> пропавшим. И все транзакции за это время как в /dev/null ушли.

Правильные multi path реализуют правильные барьеры :) да да - есть командочка такая в bio уровне.
не правильные - убивают FS в хлам. Вывод делать вам :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #37, #46

33. Сообщение от Аноним (-), 27-Май-13, 13:30   +2 +/
Толстопуз, окстись. GEOM тут ни с одной из шести сторон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

34. Сообщение от NikolayV81 (?), 27-Май-13, 13:33   +/
>> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
>> а то определить какие данные потерялись при вылете SSD будет проблематично,
>> хотя вероятнее всего самые нужные ;)
> Интересная штука, используя N x RAID1 из SSD мы поднимаем отказоустойчивость от
> вероятного "протирания до дырки" грубо в N раз, а применяя на
> них N x RAID0 мы увеличиваем ресурс в N раз, тем
> самым снижая эту вероятность.

если исключить вроде как не подтверждённую проблему "SSD зеркалу иногда имеет особенность умирать целиком", то таки в случае зеркало будет некоторое время для замены ;) ...


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #38

35. Сообщение от ананим (?), 27-Май-13, 13:45   +2 +/
С чего ты взял что я за хренами наблюдаю? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #48

36. Сообщение от ананим (?), 27-Май-13, 13:49   +/
Можно.
Но никто (в зравом уме) этого им не говорит.
Особенно на рсубд в режиме 24*7*365.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

37. Сообщение от ананим (?), 27-Май-13, 13:50   +3 +/
Мультипас не реализуют барьеры. Вообще. :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

38. Сообщение от Аноним (-), 27-Май-13, 14:38   +/
В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из устройств, следовательно оно практически не защищает от износа. В страйпе общий ресурс равен наименьшему из компонент умноженному на их количество.
Насчет времени для замены, лучше чтобы его никогда не случилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #39

39. Сообщение от NikolayV81 (?), 27-Май-13, 14:44   +1 +/
> В зеркале износ одинаковый для всех компонент, общий ресурс равен наибольшему из
> устройств, следовательно оно практически не защищает от износа. В страйпе общий
> ресурс равен наименьшему из компонент умноженному на их количество.
> Насчет времени для замены, лучше чтобы его никогда не случилось.

И к чему это? на серверах всегда выходили из строя диски, и весь смысл зеркалирования, и его "развитий" в том что бы в случае выхода из строя ( который в дата центрах является плановым событием ) в сохранении данных...
> ресурс равен наименьшему из компонент умноженному на их количество.

это неверно если вам не наплевать на данные, как бы ресурс человека не равен наименьшему ресурсу клетки помноженному на их количество...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #40

40. Сообщение от Аноним (-), 27-Май-13, 15:06   +1 +/
Если не говорить об отказах электроники, а только об износе механическом (HDD) и электронном (SSD), то картина следующая. Чем больше у нас в массиве HDD тем выше вероятность отказа. В случае механики она еще и менее предсказуема. А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс. Разницу видно?
Ну и RAID10 никто не отменял.

> ресурс человека

Потеря одной клетки не влечет за собой гибель организма.
Если организм не одноклеточный ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #41

41. Сообщение от NikolayV81 (?), 27-Май-13, 15:11   +/
> А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс.

Что вы понимаете под ресурсом?
если ресурс это возможность отдать информацию в том виде ( без ошибок ) в котором она была передана то это не так... и хоть миллиард устройств, в случае отказа не важно что останется на других, если нет копии данных которые лежали на этом устройстве ( и не важно механика там, магнитная лента, ссд или печатная продукция на складе )...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #44

42. Сообщение от Аноним (-), 27-Май-13, 15:38   +1 +/
В LSI есть CacheCade. И помнится на семинаре представителю LSI задавали вопрос: - "А что происходит и как обрабатывается ситуация, когда SSD умирает?"

Так вот он ответил, что если SSD умирает из-за ресурса, то чтение сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать можно. Т.о. ничего страшного не происходит.
Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок, и теоретически после починки данные возможно вытащить все равно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #58

43. Сообщение от Аноним (-), 27-Май-13, 15:44   +/
>> Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD,
>> а то определить какие данные потерялись при вылете SSD будет проблематично,
>> хотя вероятнее всего самые нужные ;)
> можно замутить RAID 1 из BTIER дисков =-o

Зачем? Диск переходит в RO режим. Просто выводишь RO диск из массива, ставишь новый и продолжаешь работать.
Данные не теряются. Если не может записать на SSD, пишет на другой диск.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #57, #68

44. Сообщение от Аноним (-), 27-Май-13, 15:52   +/
>> А в случае с SSD наоборот, чем бОльший объем тем бОльший ресурс.
> Что вы понимаете под ресурсом?
> если ресурс это возможность отдать информацию в том виде ( без ошибок
> ) в котором она была передана то это не так... и
> хоть миллиард устройств, в случае отказа не важно что останется на
> других, если нет копии данных которые лежали на этом устройстве (
> и не важно механика там, магнитная лента, ссд или печатная продукция
> на складе )...

Для начала подумайте, с чего бы это ресурс в SSD измеряют в циклах записи а то и просто в петабайтах. И почему в одинаковой модельной линейке SSD вдвое меньший объем заявляется со вдвое меньшим ресурсом. Если этого не поймете, то и разговаривать дальше нет смысла.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #53

45. Сообщение от Аноним (-), 27-Май-13, 16:58   +/
Неожиданный ход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #82

46. Сообщение от Аноним (-), 27-Май-13, 16:59   +2 +/
> Правильные multi path реализуют правильные барьеры

Это где такие? Ну, кроме вашего воображения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

47. Сообщение от Аноним (-), 27-Май-13, 17:01   +5 +/
> Они изобрели FreeBSD-шный GEOM для Linux и добавили местечковых костылей, вот и вся новость.

Ликвидируем безграмотность среди школьников: "FreeBSD-шный GEOM" - это просто копипаста с линуксового device mapper.

Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #50, #62, #77

48. Сообщение от Аноним (-), 27-Май-13, 17:02   +3 +/
> С чего ты взял что я за хренами наблюдаю? :D

Судит всех по себе, видимо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

49. Сообщение от Moomintroll (ok), 27-Май-13, 17:11   +/
Hot Spare не спасёт ввиду отсутствия избыточности. Если хоть один из носителей вылетит, то менять его будет уже поздно - данные потеряны. А вот Ноt Swap таки поможет, если за S.M.A.R.T.ом следить и вовремя диски менять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

50. Сообщение от Аноним (-), 27-Май-13, 17:21   +/
А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #51

51. Сообщение от Аноним (-), 27-Май-13, 17:33   +2 +/
> А можно еще сказать, что возможности ZFS, имеющиеся во FreeBSD, в линуксе реализуемы только костылями в виде BTIER и Btrfs :)

Или наоборот: возможности ZFS и Btrfs, имеющиеся в линуксе, во FreeBSD реализуются только костылями в виде ZFS.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #52, #54

52. Сообщение от Аноним (-), 27-Май-13, 17:34   +1 +/
Даже так: возможности ZFS, Btrfs и BTIER.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

53. Сообщение от NikolayV81 (?), 27-Май-13, 17:38   +/
> Для начала подумайте, с чего бы это ресурс в SSD измеряют в
> циклах записи а то и просто в петабайтах. И почему в
> одинаковой модельной линейке SSD вдвое меньший объем заявляется со вдвое меньшим
> ресурсом. Если этого не поймете, то и разговаривать дальше нет смысла.

физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка оказалось была со служебной информацией ( не я верю что эти все проблемы разобраны и решены, но что-то мне подсказывает обратное), микрокод контроллера ссд пытался работать вплоть до финиша, либо просто не память а что то другое умерло )... так что какая разница, про маркетинг по поводу ресурса на перезапись не надо, микрокод контроллера ssd не разбирали и как он будет падать доподлинно не известно ( были прецеденты и с полным отказом ). изначальный пост был о том, что все привыкли что ssd в схеме используется как быстрый большой кэш на чтение а вся записываемая инфа гарантированно сохранялась зеркальным ( избыточным ) рейдом, а у этого продукта подход другой, т.е. с точки зрения сохранности данных он считает быстрые и медленные носители одинаково надёжными...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #59, #67

54. Сообщение от Аноним (-), 27-Май-13, 17:39   +1 +/
> возможности ZFS..., имеющиеся в линуксе

Да, несчастные бсдешники уже и забыли, что с появлением zfsonlinux количество преимуществ freebsd перед linux вернулось на исторически сложившийся уровень (0).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #75

55. Сообщение от Кирилл (??), 27-Май-13, 17:56   +/
Это типа FusionDrive в Mac OS X?
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от проходил мимо (?), 27-Май-13, 18:49   +/
ssd перешел в ro,как его заменить? это raid5 из 5-ти hdd+ssd, а tier 1 = raid5 из 5 hdd + tier 2 из ssd. В самом деле, сценарий восстановления тут интересен - останов всей конструкции на замену и раздельное зеркалирование ssd, а затем сбор всей конструкции заново -  весьма слабый и непромышленный вариант.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

58. Сообщение от проходил мимо (?), 27-Май-13, 18:52   +/
> Так вот он ответил, что если SSD умирает из-за ресурса, то чтение
> сохраняется все равно. Т.е. нельзя записать новые данные, а старые прочитать
> можно. Т.о. ничего страшного не происходит.
> Если умирает электроника, то конечно все плохо. Но вылет электроники крайне редок,
> и теоретически после починки данные возможно вытащить все равно.

Смотря что вылитит, если карта реаллокации блоков - то сильно врядли... Да, вылет электроники у ssd - зависит от условий эксплуатации, и увы, не редок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

59. Сообщение от Аноним (-), 27-Май-13, 19:15   +/
Не совсем понятно, что вы хотите доказать. И кому.
Я выразил свою точку зрения на отказоустойчивость RAID1 vs RAID0 в свете другой технологии хранения данных. Постулировал что зеркало на SSD не дает преимущества в долговечности. И что скорее наоборот, RAID0 проработает дольше при том же трафике на запись. А вас понесло на ячейки и ФС. Кстати, S.M.A.R.T. ведь никто не отменял. И по сравнению с HDD там намного более точные сведения об оставшемся ресурсе. В чём спорить изволите?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #70

60. Сообщение от Аноним (-), 27-Май-13, 19:21   +/
> очередной троль

Ты настолько лузер, что даже слово "тролль" не можешь правильно написать. Позор!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

61. Сообщение от Аноним (-), 27-Май-13, 19:24   +1 +/
> Процессу можно сказать, что данные есть, "- а где  и как - тя нипёт!".

Можно. Только когда у тебя при крахе потом навороченный двигун БД не сможет отреплеить свой журнал и транзакционность факапнется - будешь писать жалобы в спортлото и копить деньги на оптовую закупку вазелина.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

62. Сообщение от Аноним (-), 27-Май-13, 19:24   +/
> Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.

В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня речи быть не может.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #84

64. Сообщение от Анонимemail (64), 27-Май-13, 21:25   –1 +/
В начальном посте сказано что данные кэшируются в озу. А чего произойдет если будет падение ноды по питанию ? Большие дедьки типа нетаппа гонят данные через nvram кэш, а тут через озу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #72

65. Сообщение от saNdro (?), 27-Май-13, 21:43   +/
Так никто и не мешает их юзать параллельно. Можешь не сомневаться. ERPD был убран из TIER автором уже вроцессе развития, что бы не дублировать код проекта. Автор, кстати, у них один и тот же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

66. Сообщение от Аноним (-), 27-Май-13, 22:02   +/
в смысле как? initrd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

67. Сообщение от Аноним (-), 27-Май-13, 22:10   +/
> физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка
> оказалось была со служебной информацией

Вы хоть почитай не про устройство фс и в каких фс как хранят данные и как работают.
А не воображариум устраивать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #83

68. Сообщение от pavlinux (ok), 27-Май-13, 22:24   +/
> Данные не теряются. Если не может записать на SSD, пишет на другой диск.

А куда они денутся? BTIER - по сути, это RAID0 в режиме FIFO,
где верх кучи это самый быстрый диск.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

69. Сообщение от pavlinux (ok), 27-Май-13, 22:28   +2 +/
> А чего произойдет если будет падение ноды по питанию ?

закупка новых бесперебойников

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #71

70. Сообщение от nikolayv81email (?), 27-Май-13, 23:00   –1 +/
> Не совсем понятно, что вы хотите доказать. И кому.
> Я выразил свою точку зрения на отказоустойчивость RAID1 vs RAID0 в свете
> другой технологии хранения данных. Постулировал что зеркало на SSD не дает
> преимущества в долговечности. И что скорее наоборот, RAID0 проработает дольше при
> том же трафике на запись. А вас понесло на ячейки и
> ФС. Кстати, S.M.A.R.T. ведь никто не отменял. И по сравнению с
> HDD там намного более точные сведения об оставшемся ресурсе. В чём
> спорить изволите?

в общем начали с этого, возможно по пути потерял где то ход мысли :(
>Главное что бы кто-то теперь не задумал RAID 1|5|6 + 1 SSD, а то определить какие данные потерялись при вылете SSD будет проблематично, хотя вероятнее всего самые нужные ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

71. Сообщение от Анонимemail (64), 28-Май-13, 01:02   –1 +/
LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода вылетела в силу каких-то причин.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #86

72. Сообщение от Аноним (-), 28-Май-13, 01:42   +1 +/
>> А чего произойдет если будет падение ноды по питанию

не закоммитить изменения на диск

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

73. Сообщение от анонимм (?), 28-Май-13, 09:29   –1 +/
Не попахивает ли тут Venti?
Ответить | Правка | Наверх | Cообщить модератору

74. Сообщение от docent (??), 28-Май-13, 10:04   –1 +/
> Например, близкий аналог flashcache может поддерживать отдельный кэш из SSD-накопителей поверх традиционных дисков, дублируя данные, в то время как BTIER максимально эффективно использует доступное пространство.

А эта эффективность нужна?
Например, размер СХД 12ТБ, для оптимизации работы достаточно SSD скажем на 200ГБ.
Т.о. получаем "эффективность" 200/12000=1.6%
Но для надежности придется использовать 2 зазеркаленых диска SSD.
Мне кажется, что использовать SSD как кэш было бы более эффективно и надежно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #79

75. Сообщение от Школьник (ok), 28-Май-13, 10:36   –1 +/
Пока zfsonlinux не появится в ядре, оно будет просто детской игрушкой для энтузиастов. А в ядре оно не появится никогда.

ЗЫ Ох, какие у нас линуксолюбивые модераторы пошли, трут неудобные комментарии на раз. А чего бы не стереть тогда уж и тот комментарий, на который я отвечаю? Религия мешает? Как можно любить free software и не любить свободу выражения мнения?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #78

76. Сообщение от amorphine (?), 28-Май-13, 15:42   –1 +/
Ну все. Теперь линукс точно готов для десктопа
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80

77. Сообщение от Кирилл (??), 28-Май-13, 16:09   +1 +/
Нет, в ZFS ничего похоже нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

78. Сообщение от ананим (?), 28-Май-13, 21:04   +/
Какая религия? Видел я твой коммент, смесь спеси, хамства и невежества.
Ау? Это ты бсд имел ввиду, говоря про энтерпрайз? Ха.
Патчинг ядра и смена форматов вообще шедевр. Ау, у zfsonlinux тотже формат и версия, что и в бсд. Какой нафиг патчинг?
Такое ощущение, что виндовые вирусы стали поражать уже и вантузятников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

79. Сообщение от ананим (?), 28-Май-13, 21:10   +/
Нужна.
Во-первых, реализации аля кэш уже есть. Пользуйтесь.
Во-вторых, вот есть у меня ноут. Двд сменил на ссд. Вот сабж более чем к месту тут.
В-третьих, в случае кэша в/в всё равно дублируется. Что может быть критично. Графики выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

80. Сообщение от Аноним (-), 29-Май-13, 06:33   +/
Дааа  ... теперь походу десктоп не готов для линукса :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

81. Сообщение от anoncppagli (?), 29-Май-13, 11:41   –2 +/
А можно простыми словами для чего оно нужно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #85

82. Сообщение от anoncppagli (?), 29-Май-13, 11:43   +/
Макароны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

83. Сообщение от Аноним (-), 29-Май-13, 15:15   +/
>> физически у вас отказ перезаписи ячейки, на практике развал фс ( ячейка
>> оказалось была со служебной информацией
> Вы хоть почитай не про устройство фс и в каких фс как
> хранят данные и как работают.
> А не воображариум устраивать.

Он о метаданных, упырь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

84. Сообщение от Аноним (-), 29-Май-13, 15:16   –1 +/
>> Также заметим, что на современных FreeBSD аналог BTIER реализуем только средствами ZFS.
> В ZFS это просто банальный кэш. Ни о каком tiering'е там сегодня
> речи быть не может.

Потому что он там в пень не уперся. Она чутка для других задач, нежели самодельное гогно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

85. Сообщение от Кирилл (??), 30-Май-13, 12:45   +/
Вот есть у вас очень быстрый ссд, но он мелкий и относительно дорогой, и есть очень большой и дешёвый, но медленный жёсткий диск. Вы можете сами раскладывать то, что по-вашему, требует быстрого чтения и редко изменяется на быстрый ссд, а жёсткий диск использовать для данных, которые не так критичны к скорости загрузки. Но как определить что куда класть, да и следить за этим нужно. В общем, слишком много мороки. А эта технология позволяет залепить из ссд и жёсткого диска один раздел, а потом сама ведёт статистку использования и решает какие файлы (или блоки) на какой физический носитель пихать. За счёт этого конечный пользователь получает и высокую скорость загрузки и преимущества большого и дешёвого носителя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

86. Сообщение от pavlinux (ok), 31-Май-13, 03:26   +/
> LOL. Ну это обойтись малой кровью. Конечно же имеется ввиду если нода
> вылетела в силу каких-то причин.

Чо, чо... только своевременные бэкапы, переодические инкрементальные бэкапы.
Такие вещи продумывают ещё до закупки оборудования. Критически важные данные
хранят на соседнем RAID61. Если работаш с БД - репликация, с файлам - сетевое зеркалирование/синхронизация.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру