Thu, Jun 22, 2006 at 09:10:49, alex wrote about "[uanog] Re: [uanog] Re: Нужны люди, желающие учиться и работать. Направление - внедрение "тяжелых" RISC-систем (Sun, IBM).":
РАИД винтов с батарейками - лечит. VN> Угу. И кластер? Так и представляю себе десять тысяч тазов, у VN> каждого RAID с батарейкой:) Или выделим отдельно хранилище, VN> отдельно процессинг? Ага, NFS между ними:))))
Я уже давал эту ссылку на "винты с батарейками" : http://www-03.ibm.com/servers/storage/disk/ds4000/ds4300/index.html http://www.superwarehouse.com/IBM_TotalStorage_FASt_EXP700_Storage_Cabinet/2...
Ну и? Что такое существуют - не надо мне рассказывать, сам настраивал (не такую модель, но того же типа). Что оно даст для данного случая? Во втором - FC/2G, спасибо - значит, если один backend работает с диском - он точка отказа, а если два - между ними возникает HAC весьма непростой организации (корректный одновременный доступ в БД и вообще на диск - задача ой нетривиальная). Гуглевое решение и то принципиально лучше с точки зрения кластеризации - потому что у них одни данные лежат на трёх хостах (если рекламные статьи не врут). Но у них слишком легко всё параллелится. VN> А я не говорил про "СуперСан". Впрочем, можно и определить подобный VN> класс задач, одним простым принципом: сложная ресурсоёмкая обработка VN> непригодная к распараллеливанию. И начинается это с баз данных.
Ок - твой "слив" защитан :)
Нет, не защитан. Вы не знаете подобных задач? Не ваша задача? Верю. VN> Давайте. Я не про Аваль вспоминал, а несколько про другие структуры VN> и системы.
Например какие ? :) Ну давайте - пример где стоит "кирпич" и от этого всем тепло сухо и комфортно, да еще и при отвале частей задачи все не падает и ТСП сессии не рвутся - я хочу услышать РЕАЛЬНЫЙ пример.
"TCP сессии не рвутся" - я уже пояснил почему не считаю это аргументом и вообще необходимостью. А места где стоит "кирпич" - извините, не могу выдавать. Да, это повод к Вашему очередному "слив защитан". Извините-с, если предыдущая работа разрешит - расскажу. Сами вендоры (вроде той же IBM) позволяют себе называть клиентов, смотрите у них. VN> Если понимать откат транзакции как новую транзакцию с обратным VN> действием - ну да, но при чём тут это вообще? Это даёт право VN> процессинговому центру валяться?
Надо лечить от лукавства :) ... Переиначу вопрос: "А что, применение "кирпича" НЕ ПОЗВОЛИТ процессинговому центру валяться ???" Зачем тогда платить больше ? :)
Нет, корректно сформулировать так: "чтобы не валялся" - задача требующая особой организации системы, и для определённых задач и начиная с некоторых требуемых уровней надёжности это может быть решено _только_ на так называемых "кирпичах". (Что составляет малую часть от всех решений класса "чтобы не валялся", с этим я никогда и не спорил.) Причина этому - по-настоящему качественное железо (в котором ситуации типа "ECC генерируется, но не проверяется") не может быть в принципе), другие средства организации уже на аппаратном уровне (позволяющие определить и локализовать сбой уже на этапе возникновения, а не когда вся система начинает идти вразнос), оптимизация архитектуры под масштабирование нагрузки и под её кластеризацию (ни того не другого у x86 никогда не было). И как следствие аппаратных возможностей - ПО которое пишется только или почти только под такое железо (и объедки которого уже достаются писюкам).
...Вот у меня, например, Цисок в провайдинге вообще нет :) раутинг на мощном писюке и Зебре - и ниче - работает месяцами без падучей и прочих проблем, несколько полных таблиц при этом держит :)
Угу, зебра умеет. А вот чуть за пределы держания трёх fullview выйти - и начинает сосать по полной, потому что полной фичастости BGP у неё не было и нет. Посему для ISP она применима только для мелкого.
Даже при том что я провожу плановую замену этого писюка раз в 1.5 года он мне окупается многократно, если сравнивать сколько бабла я должен был потратить на циску аналогичной сетевой производительности :)
Я рад за Вас:) VN> Лукавите как раз Вы. Покупатель не думает, позволяет себе впихнуть VN> то что ему не нужно - какое это отношение имеет к реальным нуждам?
Прямое - тут людей набирают чтобы "впихнуть" кирпичи, потому что Продавцу НАДО ПРОДАТЬ, а не Покупателю купить. Разницу видите ?
Разницу вижу, логики в данном аргументе - нет, по причине её отсутствия. Покупателю - если он вообще пришёл к такому продавцу - нужно нечто уровня явно выше чем два писюка. И тут действительно начинается в том числе и маркетинговая игра. А теперь смотрим исходное письмо и видим что нужны люди на ВНЕДРЕНИЕ систем. То есть ТЕХНАРИ. Итак, кто тут лукавит? По-моему - некто А.В.С.
...теперь продажа кирпичей, на думку Продавца, будет идти лучше, потому что "спецы" должны придумывать новые наукообразные методы "втюхивания" кирпичей, пользуясь своим опытом и Именем :)
Не путаете маркетоедов и технарей? По-моему - путаете:)
Вот Вы все так и не смогли мне Сан продать :) как не старались :)
Я? Не старался. Вам он действительно не нужен, я это вижу уже по постановке задачи.
VN> Мы вот на LN тоже когда-то покупали саны:) И это было реально VN> полезно - тогда такой уровень не мог обеспечить PC. И сейчас есть VN> применение в которое сколько ни впихивай писюковой мощности - всё VN> будет мало "Когда-то" - покупали, потому что денег на это вам не жалели и не спрашивали за эффективность таковых решений. :)
Потому что в 99-м PC РЕАЛЬНО не тянул то что нам надо было (а если тянул то стоил больше того Сана). И покупка оправдалась.
...помню я Лаки старых времен и слабость некоторых прошлых руководителей :) к Санам и крутым Цискам :) деньги при этом были далеко не главным фактором вообще...
Васильич, ВСЕ тогдашние вложения в железо - окупились и очень быстро. Это я Вам как достаточно беспристрастный ко всем этим переворотам внутренний наблюдатель говорю. VN> Вот выйти на 200 звонков в секунду - придётся или упрощать VN> обработку до предела, или уже серьёзно думать о том как это делать VN> - и железо будет играть не последнюю роль.
Угу - сразу видно что вы не в теме :) Кластер такое решает легко, а "упрощать" - не всегда получается, там есть свои фичи без которых нельзя.
Да, вашу систему я не видел. А кластер - вот у вас трансферы (хотя бы blind) между внутренними endpoint'ами бывают? -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message