В OpenSolaris появится storage software корпоративного уровня

> Скрипт он в совсем незамысловатый, типа рекурсия, но постить я его не стану.

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

> Со мной и так все девочки в лифте здороваться перестали.

Понятное дело - значит вскорости либо повысят, либо расстреляют.

> А что производители iSCSI карточек уже научились у заклинанию колдовать "уменьшить латентность в 3 раза"

Я пробовал только софтверную реализацию.

> Имею IMHO: http://mx.ru/Lists/CGatePro/Message/15337.html?Skin=Russian , там выше по треду тоже интересно.

Обязательно почитаю, cgp под рукой нет, но io при борьбе двух процессов за rexe файлов на zfs можно будет попробовать.

>Я пробовал только софтверную реализацию.

Ок. И как быстро оно сожрало все CPU?

скажите это у меня глюки или слова system на розовом фоне?

> Ок. И как быстро оно сожрало все CPU?

Оно не жрет все CPU. На отданном ~4G имидже нормально пахал постгрес. Мож ввиду того что типы "нагрузок разные", но опять же все поддается элементарным подсчетам.

> скажите это у меня глюки или слова system на розовом фоне?

Чееееего ? 8O

>Оно не жрет все CPU. На отданном ~4G имидже нормально пахал постгрес

Понятно, спасибо. Буду тестировать.

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

> Понятно, спасибо. Буду тестировать.

Кстати через пару дней будет аааабсолютно свободный на пару недель v210 (чем богаты так сказать). Если что iblis.al.shaitani at gmail - можно будет помучить Solaris XX std vs Solaris nevada. Во втором относительно стандартного изменений много.

>Кстати через пару дней будет аааабсолютно свободный на пару недель v21

Спасибо! (/мну немного смущен и не знает воспользоваться ли предложением :-) )

>можно будет помучить Solaris XX std vs Solaris nevada

Вот я как раз nevada'у-то вечером и хотел дома помучать.. Пост саныча на предмет 100M дир/файлов начинает выглядеть в интересном свете: накидать рекурсивно форкающуюся приблуду и смотреть когда система загнется :D

Когда речь идёт о кластеризации почтового сервера, то зачем для этого использовать кластерную файлуху? Можно ведь сделать пачку отдельно стоящих серваков, имеющих на себе smtp/pop3/imap проксю, которая содержит таблицу вида email->server. Вся эта пачка балансируется простейшим способом на днс rrset. Индекс на всех одинаковый, когда приходит smtp/pop сессия, то она редиректится на тот сервак, где лежит собственно почтовый ящик. Получаем, что единого файлового пространства нет, оно распределено, реализовать это на вменяемых масташабах (не gmail) будет возможно не так сложно. Ну ещё индекс например можно тоже держать в какой нить БД, которая стоит на хорошем рейде, а application level прокси будут опрашивать его, дабы не держать индекс на себе.

> /мну немного смущен и не знает воспользоваться ли предложением

Я же не жену предложил %). Прямого доступа конечно увы не будет - регламент, но прогнать любой набор бенчмарков / снести прогнать по новый - не вопрос.

>когда приходит smtp/pop сессия, то она редиректится на тот сервак, где лежит собственно почтовый ящик.

В итоге, как не балансируй, имеем ситуационно недогруженную одну часть серверов и ситуационно перегруженную другую часть серверов = полуперманентно стоящая раком почтовая система + неполная утилизация доступных ресурсов + при падании одного из backend'ом отказ в обслуживании локальных для этого backend'а доменов.

P.S.
Классическая схема. Весьма успешно, кстати говоря, работает.

>накидать рекурсивно форкающуюся приблуду и смотреть когда система загнется :D

Попса. Это даж у Тоненбауэма в книжке по осям написано. В самой первой главе.

>Попса. Это даж у Тоненбауэма в книжке по осям написано. В самой первой главе.

Глупые мы.. и книжек не читаем, под кроватью храним..

A kak etomozhno sravnit s CXFS ot SGI ili StorNext FS ot ADIC? Kto nibud proboval?

> > соляра это наверное выдержала без малейшего напряга?

> Проверить чтоль...

Несомненно надо проверить. Только не ошибись - 1000 миллионов вложенных каталогов, и обязательно после этого жесткую перезагрузку и дождаться окончания fsck :-)

Можно паганому енд-юзеру раздуплить - есть ли на свете FS со _структурированным_ хранением метаданных?

Т.е. не так чтобы как в свойствах документа MSO - накидал, че мог - _текстом_... А чтобы так. как я хотел - категории. ссылки. примечания. все дела... И чтобы потом найти можно было. Не что-то конкретное - а что попало....

постепенно углубляясь

> Несомненно надо проверить. Только не ошибись - 1000 миллионов вложенных каталогов, и обязательно после этого жесткую перезагрузку и дождаться окончания fsck :-)

log включать? ;) но вообще ты недобрый :)

> имеет более низкий оверхед vs. NFS + значительно более высокую масштабируемость, но более сложную реализацию.

спору нет, на fc ты получишь более низкий оверхед с точки зрения протокола

> Есть мнение, что на NFS такую конструкцию делать не надо, т.к. ложится оно под нагрузкой и с есть проблемы с локами.

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

> А чтобы так. как я хотел - категории. ссылки. примечания. все дела...

Это не задача ФС, а задача системы документооборота.

>В итоге, как не балансируй, имеем ситуационно недогруженную одну часть серверов и ситуационно перегруженную другую часть серверов = полуперманентно стоящая раком почтовая система + неполная утилизация доступных ресурсов + при падании одного из backend'ом отказ в обслуживании локальных для этого backend'а доменов.

Это при каких порядках числа адресов - такие отклонения от среднего? Или неужели запас прочности так мал?
А как же закон больших чисел (ака теорема Бернулли)?
(грубо: при 2 серверах для 500 адресов вероятность отклонения - всего на 10% - меньше 0.95, для 10k адресов - меньше 0.99 итд).
То-есть рандомально (или звристически) раскидать адреса на группы (кол-во групп << кол-ва адресов) и подогнать их количество к требуемому запасу прочности.
load-balancing в стиле divide-and-conqueror должен казалось-бы рулить в 21 веке (вспомним гугл) а расшаренный ресурс (база, NFS) должен быть только в реальных транзакционных задачах (и то - только для необходимо-транзакционной их части) к коим доставка корреспонденции (p2p) не относится (то-есть задача доставки разным пользователям - не требует взаимной синхронизации а следовательно может быть поделено. Сведение-же средне-квадратичного отклонения к требуемой величине - отдельная и решаемая задача) имхо.
То-есть я, не будучи smtp/pop-админом, и чисто теоретически (правда по аналогии с web/DB/etc-балансированием) - на стороне mitrox и для smtp/pop.
Я что-то не понимаю?

/Anode

>Или неужели запас прочности так мал?

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

>А как же закон больших чисел (ака теорема Бернулли)?

Работает, кто бы спорил.

> подогнать их количество к требуемому запасу прочности.

Ок, хорошо, сделали. Что делать с редантостью ? Как в этом случае избежать простоя при падении одного из backend'ов ?

>Я что-то не понимаю?

Вы не учитываете того факта, что почтовая нагрузка сильно пикует (например в домены одного backend'ов начинают активно заливать спам и нагрузка на него вырастает в 5-10 раз с 1000 сессий до 5000-10000, откуда ресурсы возьмем ?)

Каким образом divide-and-conqueror нам в этом случае помогает ?


P.S.

Вот мне показалось весьма интересным http://rhd.ru/docs/articles/gfs-storage/ (Пример внедрения: IP Tech AG)

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

спасибо за инфо