В ZFS появилась поддержка исключения дубликатов

> хотя... нашёл про гугель...
http://en.wikipedia.org/wiki/Google_platform

какое решение какому сливает -- это еще посчитать надо. А факапы у гугля не частые и про потери данных никто не слыхивал ни разу.

>А факапы у гугля не частые и про потери данных никто не слыхивал ни разу.

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

кстате это еще имхо аукнется гуглу когда он устаканится. яху и даблклик тоже когда-то королями были.

> реквестирую матиматик-кунов с алгоритмами вычисления максимального размера блока хэш от которого не имеет коллизий

request accepted))

Это ж очевидно ж...

Хеш-функция -- это функция, которая делает из большого текста не фиксированной длины число длины фиксированной... соответственно максимальный размер блока при которой коллизий не бывает == длине хэша.

Однако, хэш-массивы можно использовать с дополнительной проверкой коллизий: оно хоть и будет медленнее, чем без, но, всё равно, на порядки быстрее просто сравнения блоков.

ЗЫЖ Точных выкладок не приведу, ибо бухой и мне лениво... но, в целом, картина такая.

> А почему бы не проверять блоки побайтно, если совпал хеш? Коллизии тогда не произойдет. Или проверять на совпадение несколько байт из блока. Насколько я понимаю, это на порядки уменьшит вероятность коллизии.

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

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

>ибо бухой и мне лениво

>matimatik

мозги прочищаешь - от ненужных нейронов? много экранирующих нормальный доступ к бэкэнду накопилось? :))

какое решение какому сливает — это еще посчитать надо

уже давно всё подсчитали... и бдлейд системы выигрывают по следующим позициям вчистую:

1) высокая плотность размещения серваков 4U - до 14 2-х процессорных машин; и никакого cable hell :)

2) управление системой; имеются штатное, вполне себе эффективное, ПО удалённого управления; смена сервака - дело 5 секунд, и никаких кабелей; заливка и развёртываение ОС из образа - 5 минут, штатными средствами; создание эффективных кластеров, т.к. до 14 систем могут быть объединены шиной по backbone с пропускной способностью как у ракеты и т.д.

3) эффективность использования энергии; меньше блоков питания и т.п. приводит к сниженному энергопотреблению, что есть существенный «+», т.к. меньше балба за электричество платить, меньше нагрузка на электросеть, а также, косвенно, улучшается проблема с охлаждением...

4) сравнительно низкая стоимость; серверный модуль стоит около 1500$; и это не какая-то там pc, а полноценный сервак с резервированием и горячей заменой;

+ ещё «тыщапитцот» пунктов...

и это не говоря о том что обычные тачки сливают, даже простым сервакам

> мозги прочищаешь - от ненужных нейронов?

да не, просто праздную осеннюю деперессию

> много экранирующих нормальный доступ к бэкэнду накопилось? :))

не знаю, у мозга ведь параллельная архитектура, а подсчёт ошыбок никто не ведет...

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

Ну вот к примеру проблемы в апреле 2007 года были у Z-Mail (почтовый хостинг Зенона). Одна из папок в моём почтовом ящике оказалась безвозвратно утрачена (впрочем, туда сыпалась почта от неизвестных мне адресатов, то есть самые ценные письма всё же должны были уцелеть). По их словам проблема затронула всего 0.2% почтовых ящиков. Не в курсе, какая там была система, но, если я правильно понял, то там любят Solaris и FreeBSD: http://www.host.ru/support/hosting-new/versions.html http://www.zenon.net/zip/zenon.pdf http://www.zenon.net/about/publications/0554.html http://www.zenon.net/documents/old/dedicated.html

наверняка имеются только програмные реализации, но те что я устанавливал/использовал были именно програмно-аппаратным комплексом, на базе дискового массива, но с немного другим принципом работы. в довесок - ЭТО приходит уже собранным, в противопожарном рэке, по типу сейфа =)

>>Применении рейда для ускорения доступа - это совсем другая песня, там и другие типы рейдов нужны.
какие-такие другие? обычный рэйд1 на интенсивном чтении очень даже нужен.
>>Ленты это то-же зло - что и бекапирование на CD. Не масштабируемо, не знаешь - в каком состоянии архивы, переносишь головную боль на будущее и тд.
ололо, это как раз вы, со своим рсинком, не масштабируемы. не припомню ни у одного клиента, что б пользовали рсинк не по назначению.
и ленты это не только энтерпрайс, куда по вашему сливают бекапы, в так называемых, телеотелях? где сотни клиентских железок, и дисковых массивов там тоже много, только вот не для тех целей.
в догонку - ленты уже давно по 4гб фиберу умеют работать.
вопчем сдается мне, у вас в учебном заведении, недавно лекция была, на тему хранения информации...

> уже давно всё подсчитали... и бдлейд системы выигрывают по следующим позициям вчистую


да Вы не понимаете - что самое страшное в супер-энтерпрайзе - это вендор-локи.
Компании типа гугла не могут не хотеть зохавать весь мир. И для них подписываясь на определённое вендорское решение - это как отдать процент акций. Потом те вендоры будут очень долго доить не по-децки.
Поэтому для гугла полагаться на ящики, которые будут выпускаться китаем скорее всего всегда, так как быдло-потребителям всегда нужны будут писюки, а следовательно их цена будет только уменьшаться - гораздо спокойнее, чем на сжимающийся рынок блейдов и быдлоэнтерпрайзов. Ради независимости - можно даже переплатить, поэтому даже не надо считать. Всё равно независимость будет предпочтительней.
Если не согласны - вспомним как популярны были солярки, хпуксы и аиксы совсем недавно - десять лет назад - даже для простеньких веб-серверков. И закрытые решения. И что на используется в 21 веке, и где теперь санки. Посмотрите highscalability.com справа - какова архитектура больших инсталляций. Всюду - горизонтальная масштабируемость, где многое даже на шиваплагах можно запустить: только добавляй машинки - когда не хватает, и убирай сгоревшие.
Вы случайно не продавец энтерпрайз-сольюшенов?

выше речь шла о лайф-тайм архивах. Опять Вы про то что видите вокруг себя. Не надо зацикливаться. Я и мейнфреймы вокруг себя иногда вижу в энтерпрайзе, который унаследовали с прошлого века. Что теперь - S/390 всюду, включая и на новые инсталляции, пихать?
А я вам - про будущее, потерев свой хрустальный шар, и немного эхтраполируя тенденции последних лет.

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

ок, храните всё на лентах, я не возражаю. Вспомните меня через 10 лет.

Между прочим, помню подобные дискуссии каких-то ещё 8 лет назад относительно коммерческих юниксов, сольюшенов от вендоров vs Linux.
Да тот-же оффтопик как преуспел, когда везде были униксовые воркстейшены/тонкие клиенты. Он же был как раз тем самым дешёвым решением по сравнению с коммерческими юниксами и тогдашними вендор-локами. Создав со временем свой.
Сейчас гнутые проги и дешёвые железки - позволяют значительно удешевить уже в сравнении с оффтопиком, не говоря об энтерпрайз сольюшенах.
(и да, видел я шкафы от ибмов и санок. И в большинстве многое можно реализовать не хуже и значительно дешевле на базе линукса и простого железа. Зато без вендор-локов)

давайте спорить не будем, а подождём с пяток лет - и вернёмся сюда.

> А никто не подумал, что при нахождении блоков с одинаковым хешем, фс сравнит также и содержимое блоков?

1. Только при условии принудительного указания соответствующей опции 2. Ценой двукратного падения производительности

> К тому же дедубликацию можно будет вешать на отдельный каталог, не затрагивая всю ФС

На отдельный датасет, ты хотел сказать :-) В терминах линукса, на отдельный раздел.

> все важные данные, на долгое хранение, идут на ленту и ничего с ней не будет

Был один такой банк. У них аж три ленточки было. Вставили одну - магнитофон зажувал. Вставили вторую - снова зажувал. Они взял другой магнитофон, вставили третью - и второй магнитофон ее тоже зажувал. Карма.

> рэйд - 2х затраты на диски(а ведь есть не только зеркало), рсинк - 2х затраты на систему целиком.

При больших объемах, стоимость стораджа в разы превосходит стоимость процессорной банки.

>А если в файле будет набор данных, который после XOR с этой хорошо распределенной маской даст FFFFFFFFF..., то сии данные будут считаться пилот-тоном, и прочитаны не будут. Вероятность такого совпадения 2^(-320). И всеравно обнаружили _случайно_, без направленного перебора.

Я году в 2000 записал на CD файло с харда, а потом у меня не читался досовский драйвер cdrom.sys (как-то так). Проверял и перезаписывал - всё одно. Вот думаю сейчас... )

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

AABBCCDDEEFF

вычисляем хэш от него -> original_hash

меняем N байт

AABBXXDDEEYY

высичляем хэш от него -> modified_hash0

меняем другие N байт

MMBBCCOOEEFF

вычисляем хэш от него -> modified_hash1

соответственно проделываем те же модификации с новыми блоками и сравниваем хэши.

наверняка имеются только програмные реализации

я имел в виду как раз программно-аппаратную реализацию, но point был в том, что аппаратная часть, как правило, определяет способ хранения информации в то время как программная - всяческие policy... :)

ЭТО приходит уже собранным, в противопожарном рэке, по типу сейфа =)

во время установки таких мощных штук обычно происходит жесть :)

Кстати насчет ленточек - ендюзеру и мелкому бизнесу ленты не нужны: ленточка DDS-4 стоит 420 рублей за 40 гигов (10 рублей за гигабайт). Винт SATA на терабайт стоит 4000 (4 рубля за гигабайт). Мораль - можно получить полностью резервированное онлайновое хранилище за меньшие деньги (стоимость магнитофона не забываем).

да Вы не понимаете - что самое страшное в супер-энтерпрайзе - это вендор-локи.

а, вот оно как... а я думал проср^Wпотерять бизнес... :)

Компании типа гугла не могут не хотеть зохавать весь мир. И для них подписываясь на определённое вендорское решение - это как отдать процент акций.

подпишись на 4 решения и не будет никакого вендор-лока :)

Потом те вендоры будут очень долго доить не по-децки.

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

Поэтому для гугла полагаться на ящики, которые будут выпускаться китаем скорее всего всегда, так как быдло-потребителям всегда нужны будут писюки, а следовательно их цена будет только уменьшаться - гораздо спокойнее,

ага, так говорит человек никогда не видевший как микросхемы продают на вес :)

чем на сжимающийся рынок блейдов и быдлоэнтерпрайзов.

пруф иде?

И что на используется в 21 веке, и где теперь санки.

то что одна конкретная компания слила ещё ничего не доказывает... ibm, вон, мейнфреймы толкает и рада, аж от нотиков и компов избавилась

Посмотрите highscalability.com справа

while (true)
{ 
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

http://highscalability.com/youtube-architecture

ага, скалабельно, уширь :)

Всюду - горизонтальная масштабируемость

не вполне понимаю как это связано с вендор локами кои мы обсуждаем

только добавляй машинки - когда не хватает, и убирай сгоревшие.

бггг... :) а управление зоопарком, а функционал поднимать, ручками? или велосипеды пилить?

Вы случайно не продавец энтерпрайз-сольюшенов?

не-а :) даже близко не стоял

и подводя черту: а ничего что такие «вендор локовые» решения используются много где? почему, как Вы думаете, это происходит?

короче в гуглях сидят параноики, такие как столлман, ток в другую степь

и да, набор тачек хорош ещё как-то для серверных ферм, но уже, к примеру, нормальную толстую БД Вы на них не запустите

ленточка DDS-4 стоит 420 рублей за 40 гигов (10 рублей за гигабайт).

бггг... а «мафон» к ней ещё 200 штук :)

ленточка DDS-4 [...] 40 гигов

и там давно вроде по 400 Гигов, типа так:

http://www-03.ibm.com/systems/storage/media/lto_400GB/index.html

или это hp «впереди» планеты всей? :)

> и там давно вроде по 400 Гигов, типа так:

Ты знаешь, у HP по LTO4 есть ленточки и на 1.6 терабайта, но там ленточка стоит 60 баксов за штуку в штатах, ну и магнитофончик к ней каких-то жалких 3 килобакса :-) За эти деньги проще второй серверочек или дешевый массив рядом поставить :-)

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

>> То есть нам нужны всего лишь биты с плавающей запятой.
> Для этого нужно всего лишь перевести бит в жидкое агрегатное состояние, и бросить в него битонерастворимую запятую...
При этом нужно чтобы средняя плотность такой запятой была ниже плотности бита в жидком агрегатном состоянии. Иначе утонет ведь...

> при больших объёмах таких аппаратуры доишь сам себя, причём с гарантированно меньшей надёжностью

Коварный вопрос - есть две конфигурации, на которых крутятся пачками виртуальные машины. 1. 8 компактных независимых 4-ядерных машинок + разделяемый сторадж 2. Понтовый блейд-сервер на 16 блейдов, в каждом из которых по двухядернику + тот же разделяемый сторадж По деньгам выйдет примерно одинаково, но какое решение надежней? То, которое обеспечит минимальный даунтайм при произвольном отказе компонентов. Отказал любой узел - нагрузка может быть перекинута на другие, но у первого варианта изменение нагрузки менее заметно. Отказал сторадж - оба решения курят. Правда вот у блейд-сборки появляется один крайне важный компонент - собствено blaid rack. Отказал он - все блейды стоят и курят.

> а ничего что такие "вендор локовые" решения используются много где? почему, как Вы думаете, это происходит?

Ну, вариантов много, начиная с откатов, и заканчивая нежеланием разводить зоопарк, действуя по принципу "лучше два старых врага, чем один старый и один новый" :-) Но бывает и хуже - например, когда-то не было вариантов и выбрали IBM/Sun/HP/DEC. Написали кучу софта на ассемблере завязов его на специфические фичи и закрытые протоколы. И все - как бы ни хотелось слезть с иглы, а уже никак. Софтовая подвязка куда страшней чем хардварная (во втором случае можно всегда сменить вендора - цоколевка Ethernet, IP, SCSI, FC у всех одинаковая, а вот с софтом фигушки.

> бггг... :) а управление зоопарком, а функционал поднимать, ручками? или велосипеды пилить?

А что им управлять? Это кажущийся зоопарк - именно кажущийся, поскольку программная платформа одна. Вы в курсе, как в больших конторах "устанавливают" серверы на типовые объекты? Ага, либо клонированием, либо через скриптовый инсталл. И если софт надо доустановить/проапдейтить, накатывается автоматами. На все инсталяции. Там просто нет зоопарка.

>А что им управлять? Это кажущийся зоопарк - именно кажущийся, поскольку программная платформа одна.

Вот-вот. К примеру снимок файловой системы ZFS с FreeBSD x86 можно легко перенести на какой-нибудь Sun Fire T2000 sparc64 и развернуть там. А с Btrfs это не получится, так как в ДНК этой "замечательной" ФС не прописан учёт порядка следования малых индейцев и больших индейцев! (Речь идёт о порядке байтов, принятых на архитектурах RISC и Intel: big-endian и little-endian, соответственно, для тех кто не понял шутку юмора).

у HP по LTO4 есть ленточки и на 1.6 терабайта, но там ленточка стоит 60 баксов за штуку в штатах,

ну и давай посчитаем... 60$ лента... пусть доставить её стоит 100$ (хотя, конечно, в большой партии меньше будет, но пусть), 30% ест таможня, 15% накрутка оптового дилера, 18% ндс... calculating... 60 (картридж) + 100 (доставка) + 48 (таможня) + 31,2 (накрутка) + 43,06 (ндс) = $

теперь: 282,26 / (1,6 * 10^3) -> 0,18$ на гигабайт... круто, правда?

Коварный вопрос - есть две конфигурации, на которых крутятся пачками виртуальные машины.

1. 8 компактных независимых 4-ядерных машинок + разделяемый сторадж

2. Понтовый блейд-сервер на 16 блейдов, в каждом из которых по двухядернику + тот же разделяемый сторадж По деньгам выйдет примерно одинаково, но какое решение надежней?

То, которое обеспечит минимальный даунтайм при произвольном отказе компонентов. Отказал любой узел - нагрузка может быть перекинута на другие, но у первого варианта изменение нагрузки менее заметно. Отказал сторадж - оба решения курят.

Правда вот у блейд-сборки появляется один крайне важный компонент - собствено blaid rack. Отказал он - все блейды стоят и курят.

конечно, Вы правы, и именно это называют в качестве single point of failure таких систем... только вот научились с этим бороться уже, сам blade rack - это железка, вряд-ли она сломается, далее вся его инфраструктура задублирована, далее 2 источника питания, 2 сети, 2 транспортные шины (backbone)... причём, всё может заменяться «на горячую», без остановки серваков...

начнём с конфигурации с 8 машинками

8 машинок займут от 4 до 8 юнитов в стойке (в зависимости от ловкости рук инсталлеров), потребуют 8 кабелей питания, 8 кабелей ethernet, 8 оптических кабелей для fiber channel корзины (SAS, как понимаете, в данной конфигурации не подойдёт)... если по минимуму, то вроде всё, и это только удалённое управление по ssh, никаких мониторов и клавиатур, если нужны + 8 толстых kvm кабелей :)

и в случае замены ноды вы отключаете от неё минимум 2 кабеля в неудобном положении

теперь про блейд

в случае blade-сервака у вас одна коробка из которой торчит 2 кабеля питания, 2 кабеля ethernet, 2 оптических кабеля к storage... всё? да, всё... причём все компоненты это задублированы, так что надёжность серьёзно выше чем для конфигурации из 8-ми машин... а замена: открыл замочек, вынул плату сервера и всё, никаких кабелей... развёртывание ПО осуществляется централизовано при помощи специализированного софта чуть ли не в автоматическом режиме... управление и мониторинг (аппаратные средства мониторинга состояния у серваков встроены, а как там с простыми тачками?) тоже централизованы

и при всём при том межсерверное взаимодействие осуществляется куда как эффективнее за счёт быстрого backbone

как Вас такой «рас клад»? :)

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

Написали кучу софта на ассемблере завязов его на специфические фичи и закрытые протоколы.

на самом деле эта проблема стоит для любой архитектуры... а для рынка PC, довольно быстро обновляющегося сильнее в 1000 раз... или не согласны?

Софтовая подвязка куда страшней чем хардварная (во втором случае можно всегда сменить вендора - цоколевка Ethernet, IP, SCSI, FC у всех одинаковая, а вот с софтом фигушки.

так мы про хардваре гутарим, не?

долдоны же... :)

классический случай, вроде быль, но корней уже не найти

сломался дисковод, запортил дискету (потом вскрытие показало)

- слушай у меня чёт дискета не читается, дай я твою попробую

- держи

- ой, и эта тоже не читается

- дай ка я у себя попробую

итог: 2 дохлые дискеты и 2 дохлых дисковода :)

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

А что им управлять?

конечно, управление 1000 инсталляций особого затруднения не вызывает :) «сказочнег штоле»?

Это кажущийся зоопарк - именно кажущийся, поскольку программная платформа одна.

а вот фига-с два... по мере выхода из строя и замены как раз получается разношёрстный зоопарк...

и потом такие диалоги:

- Серёг, а у нас что в 18-й стройке стоит

- да фиг его знает я за неё не отвечаю...

- а кто её админил?

- Петро да Василий

Василий в отпуске, Петро уволился и хрен ты там без поллитра разберёшься :)

И если софт надо доустановить/проапдейтить, накатывается автоматами. На все инсталяции. Там просто нет зоопарка.

в теории всё тип-топ, на практике именно так на сервак с БД бухгалтерии накатывается свежая «венда» :)

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

>>2 кабеля ethernet, 2 оптических ... все?
ну тут вы погорячились, иногда необходимо на каждый блэйд по такому набору.
и + еще проводочек для lom, и не надо никаких квм =)

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

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

это да, чёт на повороте занесло :)

но тем не менее, применение blade'ов ощутимо снижает количество кабелей в стойке за счёт server interconnect и питания :)

>>во время установки таких мощных штук обычно происходит жесть :)
и таки да, один раз приходилось разбирать, два дня убили на установку )

у некоторых это выполнено именно на железном уровне

ммм... возможно, хотя я с такими не встречался :)

и да, есть мнение, что всё равно это, скорее всего, чёрный ящик с софтом... по нынешним временам чисто хардварная реализация экономически невыгодна

lom

Life On Mars, внезапно, неужели???? :)

да, не выгодно, но некоторые организации/структуры требуют. и стоит ЭТО парапапа...

ну как то так, только удаленная жизнь получается =)

однако не всегда это возможно применить, но да, экономит место и нет головной боли с кучей проводов, которые надо еще и правильно развести, чтоб можно было на ходу из стойки вытащить =)

> ну и давай посчитаем...

1. Ты "забыл" стоимость магнитофона 2. 1.5TB SATA в розницу стоит $140. Ставим его в ремовэбл-контейнер, и голы профит.

> 0,18$ на гигабайт... круто, правда?

А теперь посчитаем _эффективную_ стоимость системы хранения например, на 15 терабайт: 10 ленточек по $282 + лентовод за $2500 => $0.35 за гигабайт. Уже не так круто, ибо у SATA-винта этот показатель $0.14

только ленточный робот потребляет энергии в разы меньше. и не заставляет кондиционер лишний раз напрягаться.