Valentin Nechayev wrote:
Кластер из ДОСТУПНЫХ В ЛЮБОЙ МОМЕНТ на замену компонентов - всегда лучше "тяжелого кирпича" - даже спорить на эту тему не буду.
VN> А вот поспорьте. Хотя бы для того, чтобы ОТЛИЧАТЬ виды кластеров и VN> потребности их реализации (To all: извините за Caps, ситуация VN> обязывает). Ах, гугль, ах, двадцать тысяч писюков с помойки! Так у VN> гугла и требования к каждому узлу такие же - подумаешь умер диск, VN> подумаешь умер другой, третий - поисковый робот найдёт всё заново. VN> А теперь представим себе такой же подход к финансовой информации... VN> ась? То же самое. С точки зрения философии - это система хранения информации. Вопрос в том, что SAN'ы со всеми фичами онлайновых снапшотов и multipath уже есть, а вот в случа гугла писать надо *всё* руками, вобще всё. VN> Кластер кластеру рознь. Если задача легко паралеллится - флаг вам в VN> руки! Тогда действительно ставьте стадо писюков, автоналивайку VN> задачи и вперёд. Только вот беда - не получается *все* задачи такими VN> сделать, ну хоть убейся об стену - не получится. Покажи что нельзя параллелить в концепте системы массового обслуживания, для которых кластера и делаются. VN> А для серьёзных high availability исполнений могут требоваться VN> задачи которые в принципе не решаются писюковым железом - потому что VN> оно не умеет должный уровень самоконтроля и восстановления после VN> ошибок, оно всё работает по принципу "Семь бед - один Reset". А оно работает по стандартному ACID механизму: не сработала транзакция, откат, выкинули писюк из пула.
Иначе-бы кино в Голливуде снимали-бы на сверхтяжелых Санах, а не на кластерах - как сейчас. К тому-же опыт Онлайновых игр показывает - что "десятки тысяч клиентов онлайн" - держит почему-то именно кластер, а не супертяжелый Сан... :)
VN> Кино снимать - это ещё один гугль, потому что отдать каждому тазу VN> свой кусок картинки и затем их сложить - и первокурсник сможет. VN> Плохой пример. Та не, это в концепте голливуда - плохой пример, с точки зрения гугля - это задача, извините, нiiб@цца. Гугл - это система менеджмента информации со своим архетипом. Система банкинга, биллинга, короче любая система работающая по принципу клиент->API->бизнес_логика->система_хранения подчиняются правилу гугл-лайк. Софт, работающий в режиме атомарных коротких операций уже подчиняется этому правилу. VN> EVE-ONLINE, говорите? Заходим на первую страницу: VN> === cut === VN> Мы собираемся поставить новый патч серии Bloodlines во вторник, 6 VN> июня. Всвязи с этим, ДТ начнется в 11.00 по Гринвичу (GMT) и VN> закончится в 15.00. VN> === end cut === VN> в нормальных системах (а не игрушках) downtime подобного типа вообще VN> не бывает (всё меняется на ходу), а если бывает - то сводится к Еще и как бывает. Load testing можно провести только на живой системе, причем если у тебя меняется API внутри, то без "все встали, потом сели" не получится. Другое дело, что планируемый downtime может быть между 11 и 15-ю часами, а собственно сам downtime может быть незаметен. С точки зрения аппликух tcp'шного типа произойдёт разрыв сессии с конкретным фронтендом со всеми вытекающими. VN> секундам, а не часам. Это азы, и странно что их приходится VN> объяснять. VN> Вместо подобных игрушек лучше посмотрите на систему... мнэээ... VN> бронирования билетов. Общую по стране. Там такой downtime VN> допустим?:)) Ты на наши банки посмотри ;-) -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message