Все новости от 20 октября 2003 г.

Трансатлантические отказоустойчивые кластеры

Через три минуты тридцать пять секунд после того, как у американской ноды отключили питание, а ее хранилище данных отключили от корпоративной сети, ирландская нода запустила сетевые сервисы, СУБД и приложение, после чего на ней запустили выполнение теста.

Первенство в «трансатлантическом тесте» у EMC и Fujitsu Siemens оспаривает VERITAS, утверждающая, что уже демонстрировала подобные решения. В ответ EMC утверждает, что решение VERITAS не обеспечивает необходимой функциональности и не было продемонстрировано на реальном приложении. Спор о приоритете может завести нас в такие дебри технологий, что лучше оставить заявления на совести компаний и попробовать разобраться в технических деталях решения от EMC и Fujitsu Siemens.

В каждом центре были установлены серверы Primepower 400 под управлением Solaris 8 с установленной СУБД Oracle8 и SAP R/3, система хранения данных Symmetrix DMX800, сетевая инфраструктура и соответствующее программное обеспечение. Ноды общались через трансатлантическую сеть ATM Sonet с относительно небольшой пропускной способностью. Собственно, основная техническая новость, помимо дальности связи, заключается в новом способе обеспечения связи между нодами с помощью технологии Symmetrix Remote Data Facility/Asynchronous (SRDF/A). В основе этой технологии лежит кэширование операций записи на диск с помощью технологии Delta Set. При этом все операции записи на основной ноде не передаются на резервную ноду немедленно. Для уменьшения трафика они собираются в Delta Set. После заполнения текущего Delta Set начинает писаться новый, а старый передается на резервную ноду, где заносится на диск. Delta Set может работать в обе стороны, то есть после возвращения в строй поврежденной основной ноды Delta Set может быть передан обратно для исправления ошибок. EMC утверждает, что при использовании такой технологии можно существенно снизить требования к пропускной способности канала (WAN), соединяющего локальные сети (LAN) между двумя нодами, и существенно сократить время восстановления системы.

Следует отметить, что технология SRDF/A приводит к потере части данных при переключении со сбойной ноды.

Распределенные и кластерные решения не являются новостью для мира компьютерных технологий. Один из пионеров в области отказоустойчивых решений, DEC уже много лет демонстрирует подобные системы. В свое время в США был реализован проект, где около 30 серверов, расположенных в разных штатах, были соединены в отказоустойчивую систему. Но системы, расположенные по разные стороны океана, пока являются достаточно редкими.

Какие альтернативы существуют для подобного решения? В первую очередь, это обычная репликация данных. Такое решение существует достаточно давно, и компании Cisco и Nortel уже демонстрировали такую репликацию на большие расстояния. Главным недостатком этого решения является меньшая оперативность по сравнению с SRDF/A, а главным достоинством — отсутствие потери данных. У EMC есть подобные решения. В случае, если необходимо обеспечить работу без потери данных, EMC рекомендует использовать SRDF/AR (Automated Replication). Однако эти решения требуют большей пропускной способности или синхронизируются не с такой частотой. Трудно оценить, к каким последствиям может привести потеря данных. EMC заявляет, что данные в приложении (SAP) остались согласованными и что на этот процесс ушла большая часть времени запуска резервной копии, но не приводит убедительного описания механизма, обеспечивающего целостность базы данных. С нашей точки зрения, СУБД вряд ли можно отнести к приложениям, которые спокойно перенесут потерю части данных.

Вопрос о целесообразности такого решения, предложенного EMC и Fujitsu Siemens, остается открытым. С одной стороны, многие СУБД, например Oracle, давно имеют соответствующие возможности. В простейшем случае вторая нода кластера находится в режиме hot standby, то есть рабочая нода постоянно сообщает запасной о произошедших транзакциях. При сбое основной ноды резервная нода становится основной. Этот метод генерирует больший объем трафика, но обеспечивает целостность данных и прозрачное переключение пользователей на резервную ноду. В описанном эксперименте всех пользователей, а точнее генератор нагрузки, имитирующий работу 600 пользователей, пришлось сначала отключить от неисправной ноды, а потом заново запустить для резервной. Поскольку данная технология осуществляет прямой доступ к данным на диске в обход встроенных в СУБД механизмов обеспечения целостности данных, то пока не очевидно, можно ли в такой архитектуре использовать хорошо отработанные программные решения по обеспечению бесперебойной работы от производителей СУБД. Соответственно, значительно увеличится нагрузка на администраторов систем.

Необходимость в отказоустойчивых решениях сегодня, после атаки на WTC и массовых отключений электроэнергии в различных странах, не вызывает сомнения. А глобальность корпораций и компьютерных систем требует возможности разнести компоненты системы на максимально большие расстояния. Альтернатива, стоящая сегодня перед разработчиками таких систем, проста: или использовать репликацию и подобные решения, но смириться с огромным трафиком и необходимостью гарантировать высокоскоростной канал, или выбрать асинхронную модель типа SRDF/A и смириться с потерей части данных и сложностью управления.

Может показаться, что этот пример относится к очень узкоспециализированным и редким ситуациям. Но рост интереса к grid (utility computing, adaptive enterprise и прочие синонимы) рано или поздно поставит подобную задачу перед производителями grid-систем, а рост числа демопроектов говорит о том, что эта тема становится весьма горячей.

Послесловие

Обсуждение проблем целостности СУБД с представителем EMC в России позволило уточнить вопросы обеспечения целостности СУБД при сбое основной ноды.

При передаче Delta Set на резервную ноду копируются все изменения и log-файлы СУБД. Естественно, в момент сбоя на резервной ноде могут существовать незаконченные транзакции. Но запуск резервной ноды происходит в режиме восстановления после сбоя, и собственные механизмы восстановления СУБД обработают все незаконченные транзакции. Фактически эта ситуация соответствует той, когда СУБД запускается после сбоя, например сбоя питания, в обычной, не кластерной конфигурации. Конечно, часть операций будет потеряна, но целостность базы сохраняется.

Влияние такого сбоя на приложение будет несколько большим. Дело в том, что в отличие от СУБД сложные системы не обеспечивают автоматическое восстановление после такого сбоя. Рассмотрим пример SAP SD benchmark. Процесс ввода состоит из 16 этапов, включающих создание заказа, ввод пяти позиций, ввод данных по доставке, просмотр заказа, изменение адреса доставки, создание счета и еще целый ряд других операций. Внутреннее представление такой операции неизвестно, но, по данным SAP, она состоит из шести транзакций в понимании СУБД. Соответственно, может сложиться ситуация, когда на резервной ноде полностью скопированы только несколько из них. Внутренние механизмы СУБД обеспечат целостность данных, но некоторые транзакции могут быть потеряны. При этом пользователь SAP будет в полной уверенности, что он выполнил все операции, реально же в резервной системе бизнес-процедура не будет закончена. Это ситуация будет характерна не только для SAP, но и для большинства других бизнес приложений.

Автоматическое восстановление системы в такой ситуации обычно не предусмотрено ее производителем. Соответственно, необходим определенный уровень ручной работы: информирование пользователей о произошедшем сбое с просьбой проверить свои операции, работа администратора по поиску зависших операций и т. п. Но при этом в правильно написанной системе сохранится определенная «целостность бизнес-данных».

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

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

Михаил Елашкин — директор компании Elashkin Research, занимающейся исследованиями Enterprise-рынка. До этого много лет работал в компаниях Oracle, Novell и Intel.

 В продолжение темы:

Обсуждение и комментарии

	C3Man - semdiyahoo.com 20 Oct 2003 7:00 PM
можно по подробней о технологиях типа Delta Set? это что? transaction log типа?
	Михаил Елашкин - mikeelashkin.com 20 Oct 2003 8:52 PM
2 C3Man У меня есть несколько открытых документов по этому вопросу, но беда в том, что я их не имею право выкладывать (copyright однако). Вот где есть немного описания: http://www.fujitsu-siemens.com/rl/products/software/disaste r_recovery.html там справа есть линки на документы, но нет главного. Описания эксперимента, где подробно рассказано про Delta Set. В общем, моим корявым языком. Это не лог транзакций в смысле СУБД, а хранящиеся в памяти все операции записи на диск в ходе работы приложения пишутся в DS. Когда он заполняется, стартует новый сет, а старый посылается на вторую ноду. Там он пишется на диск. Конечно лучше читать оригинал. Попробую его найти.
	Михаил Елашкин - mikeelashkin.com 20 Oct 2003 8:53 PM
2 C3Man Нашел! Смотри http://www.emc.com/pdf/news/h1063_srdfa_primecluster_ldv.pdf
	C3Man - semdiyahoo.com 20 Oct 2003 10:02 PM
thanks, смотрю.
	Михаил Елашкин - mikeelashkin.com 21 Oct 2003 9:30 AM
Народ, я тут получил очень инересные комментарии от EMC по поводу целостности данных. Я попросил редакцию положить их вместе со статьей. Ждите.
	Витёк - lipinmail.ru 21 Oct 2003 10:21 AM
По поводу целостности - не будет её, если не интегрироваться с приложением сильно-сильно. Т.к. лог СУБД и лог дискового массива есть вещи между собой слабо связанные. Был бы приятно удивлен если это не так.
	СтранниК 21 Oct 2003 10:50 AM
Витёк По поводу целостности - не будет её, если не интегрироваться с приложением сильно-сильно. Т.к. лог СУБД и лог дискового массива есть вещи между собой слабо связанные. Был бы приятно удивлен если это не так. === Потенциально это возможно. Например если использовать RAW девайсы. Но как себя Oracle в этом случае поведет, кто-его знает. Я думаю ,не без основания, что под такие "эксклюзивные решения" Oracle специально затачивает и сертифицирует свой продукт. То есть возможно что эта штука будет работать корректно , только в строго определенных условиях на сертифицированой конфигурации Oracle-ом
	Михаил Елашкин - mikeelashkin.com 21 Oct 2003 11:10 AM
2 СтранниК На самом деле все работает и без сложных механизмов. Фактически старт резервной базы соответствует запуску обычной базы после сбоя (например питания). Также обрабатываются логи, откатываются назавершенные транзакции итп. Большинство СУБД имеет встроенные средства восстановления после такого сбоя. С приложениями немного хитрее...
	Михаил Елашкин - mikeelashkin.com 21 Oct 2003 11:17 AM
2 СтранниК Вот, zdnet опубликовал дополнение к статье, где описан механизм восстановления после сбоев. См.
	REAL - realkemsu.ru 21 Oct 2003 12:03 PM
Михаил: статья, конечно, интересная, но лично я, извиняюсь, до сих пор с нетерпением жду статьи про ИИ :)
	Михаил Елашкин - mikeelashkin.com 21 Oct 2003 12:25 PM
2 REAL Это будет в конце ноября. Я съезжу в Новосибирск. Поговорю с "Муркошкой". Сотворим.
	PTO - ptokgb.ru 21 Oct 2003 1:25 PM
2 Михаил Елашкин: нечто типа дельты я в свое время наблюдал в продукте под названием Октопус Сервер - там стояла приблуда после кеша, но перед драйвером дисковой подсистемы, перехватывала команды на изменения чего-либо, паковала и эти дельты отправляла на резервную машину одновременно с проваливанием данных в драйвер диска, т.е. потери данных быть не могло. реализованно все было чисто программно, потом по похожему сценарию работал Double Take и ихний же GeoCluster решение - мы развлекались зеркалированием базы данных из России в США... вот только не знал, что это настолько круто, что про это может сам Елашкин написать :) Муркошке привет, все никак не соберусь к ней поехать... да и блин загрузка последние пару месяцев у меня просто чумовая, не сдохнуть бы...
	Михаил Елашкин - mikeelashkin.com 21 Oct 2003 1:57 PM
2 PTO Ты посмотри ссылки, которые чуть ниже. Я собственно только суть рассказал, а обвязка там достаточно сложная. Там еще кучу сервисов надо запустить. PS ОФФ А загрузка действительно бешенная. Ты на ИТ Форуме или CIO World будешь? Что до Новосибирска, то я там 15-17 читаю лекции в НГУ. Два дня для ИТ специалистов и день для студентов. Хочешь тебя пристрою? Проект не коммерческий.
	PTO - ptokgb.ru 21 Oct 2003 6:42 PM
2 Михаил Елашкин: не, в копенгаген не хочу :) я буду на ИДФе в Москве, потом коммандировка на север западного побережья... мож в Редмонд таки заеду :), и потом тока на "Платформа 2004" сможем встретиться... кстати, если там кто будет, можем сесть пивка попить :)
	Михаил Елашкин - mikeelashkin.com 22 Oct 2003 9:21 AM
Вот напишешь нормальную статью и никто не комментирует :( все понятно сразу :)
	Муркошка 22 Oct 2003 10:15 AM
Вот почти ничего не поняла, и тем более с удовольствем выскажусь! Мир все-таки похоже непознаваем и велик и разработчики софта помогают ему таким оставаться. Скоро впору строить большие экспериментальные установки для исследования описанных в статье явлений. "Ораклотроны". Вообще же про строительство и управление сложными системами я, как полный дилетант, знаю только интересные разработки в области тензорных методов для разного рода сетей. Работы Крона. В России - П.Кузнецоы, Арменский. Насколько я знаю в США это метод вообще не нашел своих последователей. А вот в Японии его проходят во всех вузах для инженерья. По типу объекта и (вроде бы по процессам) методы похожи на то, что описывает Михаил. Миш, скоро статью про это дело на свой сайт выложу. Может чем пригодится? Все ж таки один из методов системного анализа..
	СтранниК 22 Oct 2003 11:16 AM
2Михаил Елашкин Прошу прощения , а где дополнение? Что-то не могу найти, как статья называется ?
	ggv 22 Oct 2003 11:34 AM
Да как бы что обсуждать? Провели эксперимент, говорят - успешный, интересный резудьтат - 30 секунд это таки хорошее время, вот еще доточат до той стадии чтобы всё это transparent для клиентов, назначат прайс, продадут достаточное кол-во, и вот только тогда начнеться самое интересное - читать mail-list & news-group где тусуються админы всего этого. Вот они-то всю правду и скажут. Правда, СтранниК ? Скажешь ? Вот тогда и появиться информация к размышлению.... для таких циников и консерваторов как я :)
	Пётр 22 Oct 2003 11:53 AM
2 Муркошка. А дайте ссылку на Ваш сайт. Вы как я поныл занимаетесь искусственным интеллектом? Мне вот интерсно, что нового сейчас есть в этой области, сам когда выпускался по этой специализации.
	Муркошка 22 Oct 2003 12:17 PM
Пётр == А дайте ссылку на Ваш сайт. == не дам. я тут инкогнито. Вот Михаил статью напишет, а там посмотрим. А насчет передового края... Вот анекдот. ==== Командир дивизии получил по рации донесение от одного из своих подчиненных, что тот со своими подразделением попал в засаду и окружен танками противника. - Вы неправильно докладываете, - ответил генерал. – - Ваше подразделение НЕ окружено. Вы просто наступаете в четырех направлениях!
	ggv 22 Oct 2003 12:25 PM
Муркошка - это не анекдот совсем. Это НОРМА, воспитываемая годами, вбиваемая в голову, некоторой части могучей и непобедимой сначала Советской, сейчас Российской Армии. Цель - добиться такого состояния, что личный состав вполне осознает себя одноразовым изделием, и ничего не имеет против этого. Хотя есть пример и не-одноразовости - вяземская операция, 4 корпус, четыре месяца в тылу. Со своими соединялись уже почти летом, будучи в валянках. Так что генерал сказал абсолютно правильно, если он токо не мотострелецкий и не трак.
	Муркошка 22 Oct 2003 12:32 PM
22 октября, 2003, 12:25 - ggv ага. на фронтах ИИ именно так. Слава Богу, валенок пока хватает. осталось найти кого-то типа генерала.
	СтранниК 22 Oct 2003 12:57 PM
ggv Да как бы что обсуждать? Провели эксперимент, говорят - успешный, интересный резудьтат - 30 секунд это таки хорошее время, вот еще доточат до той стадии чтобы всё это transparent для клиентов, назначат прайс, продадут достаточное кол-во, и вот только тогда начнеться самое интересное - читать mail-list & news-group где тусуються админы всего этого. Вот они-то всю правду и скажут. Правда, СтранниК ? Скажешь ? Вот тогда и появиться информация к размышлению.... для таких циников и консерваторов как я :) === Да откуда достаточное кол-во? Оно будет стоить просто бешеные деньги. Я просто заметил , что новые "цацки" стоят целое состояние. Это почти как история с системами на Итаниумамах. Результаты сумашедшие, а систем продано мало. Вот недавно общался со знакомыми, их контора покупает HP cерверы под кластер. Так вот специалисты рекомендуют пока технология Itanium не устоялась использовать cистемы на PA-RISC. Странно почему? А что в итоге? Вместо Oracle 8i Parallel Server ,внедрят только HA-кластер. Смешно не правда ли? Ну а если по теме. Мне все больше и больше нравиться решение со stabdby. Тем более что начиная с версии Oracle 9i, последний лог не теряется вообще , то есть гарантируется полное восстановление в случае полного выхода сервера из строя.
	ggv 22 Oct 2003 1:04 PM
СтранниК - ну с Itanium пока и так всё чсно, что всё темно, и что надо погодить, а те же PA-RISC ох как долго еще смогут работать, уж затраченное на них они вернут факт. Ну а со всем остальным - согласен, в том числе и по качуству HP-UX :) А вот Irix от SGI совсем не плох.
	СтранниК 22 Oct 2003 1:08 PM
Я пытался недавно оценить возможно ли получить дешевую кластерную конфигурацию, но с гарантие надежности. То есть напримео Oracle9i RAC на Intel-ах. И простоенькая FC-ая стоечка. Все класно , но вот если стоечка по какой-либо причине выйдет из строя. То кластеру - смерть. Выход в том чтобы поставить две стойки и делать реплицирование. Не прав да ли все просто? Только вот для стоек типа MS1000 таких решений нет. А самый дешевый репликатор от HP начинаеться с 300к и работает на железе которое стоит не меньше. Итого если мене надо систему , которая имела бы 30 сек восстановление воспользоваться "стандартными строительными блоками" предлагаемыми HP не получиться. Просто компаниям это не выгодно. Но если у меня системы не 1000 пользователями а скажем с 100 , но требует восстановления за 30 сек, то я что должен платить как за 1000?
	СтранниК 22 Oct 2003 1:09 PM
ggv СтранниК - ну с Itanium пока и так всё чсно, что всё темно, и что надо погодить, а те же PA-RISC ох как долго еще смогут работать, уж затраченное на них они вернут факт. Ну а со всем остальным - согласен, в том числе и по качуству HP-UX :) А вот Irix от SGI совсем не плох. === Мне в свое время Aix понравился.
	СтранниК 22 Oct 2003 1:12 PM
В продолжении. Просто есть некоторые маркетинговые ходы у того же HP. Например на тестах TPC-C используется дешевые железки чтобы показать какие мы классные , и какая у нас низкая стоимость транзакции, а в жизни начнешь заниматься и .... ж...жж-а. То купите то, то возьмите это. А "это" - уже другие деньги и естественно другой сказ.
	ggv 22 Oct 2003 1:24 PM
СтранниК - а он мне и сейчас дико нравиться. Ну до того user-friendly OS, что просто диву даюсь. Само собой про стабильность и прочее я и говорить не собираюсь. Если есть некоторый навык и так сказать, психологическая готовность работать с IBM, у которой свой особый взгляд на всё, и у которой дока по ip filter находиться в разделе IP Security - многие тут же связывают название раздела с IPSec, и как бы не догадываються там искать ip filter, но ведь по большому счёту filtering и есть часть IP Security, но там прям в начале много всего по IPSec, что и отпугивает народ - то вот если к таким вот особеностям привыкнуть, то всё остальное просто замечательно. У меня вот сейчас на нем стоит IBM DB2 & IBM LDAP, при чем различные версии пакетов смешаны, установлены вместе, используються последние версии, в любой момент могу откатиться до предыдушей версии, там у них такая политика на весь софт включая ОС... Интересная система. Tivoly - вообще песнь песней. Ну и так далее. Но тот же софт IBM просто великолепно живет на SUN, просто замечательно. И повидимому пока IBM не собираеться бросить поддержку платформы конкурента. Что дает просто замечательную возможность выбирать решение.... ВОт мы опять выбираем сейчас, опять сервер, опять под базу.
	СтранниК 22 Oct 2003 2:18 PM
У меня вот сейчас на нем стоит IBM DB2 & IBM LDAP, при чем различные версии пакетов смешаны, установлены вместе, используються последние версии, в любой момент могу откатиться до предыдушей версии, там у них такая политика на весь софт включая ОС... === Можно по подробней, а как насчет удовлетворения зависимостей между пакетами ? "Что дает просто замечательную возможность выбирать решение.... ВОт мы опять выбираем сейчас, опять сервер, опять под базу. " Если бы мне пришлось выбирать между Sun и IBM для серверов БД, то я бы выбрал IBM.
	ggv 22 Oct 2003 2:52 PM
СтранниК - по поводу выбора IBM vs SUN есть хорошее сравнение серверов pSeries с санами, так вот выглядит что соотногения цена/производительность на стороне сана, лучше у них с этим, ну и внутренние факторы. Ну как - все станции разработчиков у нас - саны. А по поводу удовлетворения... Там как то AIX сама выбирает, как и какую версию проинсталлированного пакета использовать, если несколько из них есть, никогда не сталкивался с противоречиями в пакетах, но и никогда не вникал как это всё устроено. Просто когда надоест многообразие пакетов - выполняеться Commit для нужного пакета, и все его конкуретны просто исчезают. До Commit они со-существуют. Я таки уверен это описано в AIX доке которая есть на сайте IBM, если будут проблемы с ее нахождением - могу помочь урлом
	ggv 22 Oct 2003 3:17 PM
кстати, обзор был в рассылке от elashkin research, если я не путаю, pSeries vs SUN
	Михаил Елашкин - mikeelashkin.com 22 Oct 2003 10:11 PM
2 СтранниК Уф, весь день был на ИТ Форуме, вел круглый стол по серверам. Завтра с утра ВЕА, после обеда еще один круглый стол на формуме. Работать то когда? :))) >Прошу прощения , а где дополнение? >Что-то не могу найти, как статья называется ? Если еще не нашел, то его прикрепили к тексту, называется "Послесловие". Я поговорил с ЕМС, они разъяснили как происходит восстановление резервной ноды и почему Oracle после этого выкарабкивается. >Например на тестах TPC-C используется дешевые железки чтобы показать какие мы классные Увы, компании научились "оптимизировать" результаты ТРС-С. Снала производительность, потом цену. Я в первый раз заметил это у IBM. Они выложили тест, производительность ОК, а цена неудачная. Так они диски SATA поставили и все в шоколаде (но может и они не первые). Другое дело, что надежность SCSI намного лучше. Сам тест должен проработать 20 минут. Ну отладка, настройка итп. Итого - сия конфигурация не факт что жизнеспособна.
	Михаил Елашкин - mikeelashkin.com 22 Oct 2003 10:13 PM
2 ggv >pSeries vs SUN Там потом ИБМ прислал файл с объяснениями что некорректно в обзоре. Читать рекомендую оба. Выложить его не имею права, но если кто запросит мылом, то пришлю.
	Бармаглот 22 Oct 2003 10:17 PM
2МЕ: Разнесенные кластеры - не ново. Первый разнесенный кластер был сделан на RDB/VMS бог знает в каком году промеж Атлантик Сити и Лас Вегасом. То что технология наконец-то дошла до UNIXа - великое дело. Честь, так сказать, и хвала...
	ggv 22 Oct 2003 10:21 PM
Михаил Елашкин - да я уже со спецами по pSeries успел пообщаться, и они точку зрения IBM довели до моего сведения, так сказать.
	Михаил Елашкин - mikeelashkin.com 23 Oct 2003 12:50 AM
2 Бармаглот Дык! У меня давно мнение, что все самое хорошее сделал DEC :) До сих пор только OpenVMS и IBM это делали на дальние растояния. Но вот трансатлантик пока редкость. Очень далеко :( Как у нас от Москвы до самых до окраин. Сегодня, кстати, на ИТ Форуме слушал выступление Михаила Сенаторова, заместителя Председателя Банка России, по теме "Вопросы безопасности ИТ-систем". Был приятно удивлен - насколько умно, грамотно и просто он говорил. Я думал, что читая западные обзоры, я уже все слова слышал... зря так думал :( Там была масса интересного, но в частности (и это была не самая интересная часть) он размышлял о катастрофах и 9-11. Большинство банков имело резервные центры, но...! Они были либо завязаны на того же провайдера, либо территориально были на том-же Мандхеттене. Все навернулось. При катастрофе не просто происходит повреждение одного узла, а всплеск попыток обойти убитую зону и он валит уцелевшие участки. Так ЦБ не мог несколько дней после 9-11 работать с западными банками. В общем повалились костяшки домино... В случае если чего шарахнет, то даже резервный центр за городом не спасает. Часть ИТ народа не сможет до него добрататься из-за паники и пробок, а часть ... увы, они уже не смогут. Поэтому ЦБ размещает центры по стране. Они выполняют свою долю общей работы, но у них есть тренировки по перехвату управления в случае катастрофы... В общем, получил удовольствие от слушания умного человека. Это я так коряво его речь рассказываю и далеко не всю, только относящуюся к катастрофам.
	eXOR 23 Oct 2003 4:57 PM
2 Михаил Елашкин: О! 15-17 ноября? Круто. Обязательно буду ;-).
	Михаил Елашкин - mikeelashkin.com 24 Oct 2003 12:59 AM
2 eXOR По Новосибирску информация здесь: http://www.elashkin.com/document.asp?ob_no=511 Там 15-16 будет платное. Это не мой заработок, а так сказать налог на поддержку НГУ.
	eXOR 24 Oct 2003 2:07 PM
2 Михаил Елашкин: Гы :-). г-н Диканский все бабло гребет... когда ж его уже... ;-). Ну да не страшно, только бы одному там не оказаться ;-)...
	Михаил Елашкин - mikeelashkin.com 25 Oct 2003 2:37 PM
2 eXOR Ну, я договаривался с Авдеевым (ФИТ, замдекана). А вообще, на ИТ Форуме я говорил с кучей народа и есть идея: у нас "жопа" с обучением в универах. Слишком много народа уехало или ушло в бизнес. Поэтому я предложил акцию "Отдадим долги". Идея в том, чтобы специалисты из ИТ прочли хоть одну лекцию в университетах. Взяли и прочли. Бесплатно. Для студентов. У меня за один день набралась куча лекторов. Беда в том, что в основном в Москве, но народ ведь ездит проводить разные семинары в другие города. Плюс есть местные. Я пока договорился с Мариной Никитиной (CRN), что мы подумаем как организовать народ и универы. У меня самого нет столько времени, а вот журнал может помочь с организацией. Как там Ильич говорил - "коллективный организатор". А что в универе на этом наживутся? Дык, пускай. Главное чтобы студентам знания достались. Мне не жалко, если пара руководителей на мне заработает. Имея возможности заработать, глядишь больше народа толкового в универах останется.
	eXOR 27 Oct 2003 7:30 AM
2 Михаил Елашкин: В том-то и проблема. Знания достанутся не тем, кому они нужны, а тем, кого допустит декан. Свободного входа в НГУ уже нет, а значит пройти смогут только студенты. Вход будет платным, а значит пройти смогут не все, а либо мажоры, либо работающие (кстати университет относится категорически отрицательно к работающим студентам). (хотя для тех кто хочет всегда есть лазейки)... А вообще начинание классное. Долги не долги, а вот обмениваться знаниями - это всегда полезно :-).
	REAL - realkemsu.ru 27 Oct 2003 7:42 AM
"кстати университет относится категорически отрицательно к работающим студентам" Смотря какой. Наш универ только ЗА.
	Михаил Елашкин - mikeelashkin.com 27 Oct 2003 11:00 AM
2 eXOR надо сообразить. 4 часа для студентов будет бесплатно - это мое условие. Причем студентов любых факультетов и курсов. 16 часов, да. Это платные будут для ИТ специалистов. Тут я не могу ничего сделать. Единственно, сейчас пытаюсь договориться с Sun новосибирским, чтобы они оплатили сколько-то мест для своего списка специалистов. Можно мне на мыло, если есть проблемы. Я помогу с пропусканием. Что до студентов, то надо будет поговорить насчет работающих студентов. Я сам в МГУ работал на пол-ставки с 3-его по 5-й курс. А потом в аспирантуре. Как же можно студентам не давать работать, особливо по специальности? Конечно не во вред учебе.
	Муркошка 28 Oct 2003 7:51 AM
Мдыыыаааа... Диканский и впрямь бизнес осваивает. Только лучше уж он, чем прошлый товарищч. Я училась на ФФ, когда Диканский был в каких-то заграничных пампасах. И его, надо сказать, очень ждали. Я тоже тут немножно к этому прикоснулась. Дело хорошее, организовывать только надо тщательнее. Есть же наверное какой-то опыт у других вузов, у западных? Должен же быть какой-то алгоритм - какие действия делать и в какой последовательности. И это почему к работающим студентам плохо стали относиться? раньше не было этого. самое время набирать первый жизненный опыт. Этому же в универе не учат...
	REAL - realkemsu.ru 28 Oct 2003 8:30 AM
"Дело хорошее, организовывать только надо тщательнее." Вы про "Вернем долги"? Да, очень хорошее. Вот только зная моральный облик многих наших бизнесменов ("а что мне за это будет?"), надежды на то, что это выльется в регулярную практику, у меня маловато :(
	Михаил Елашкин - mikeelashkin.com 28 Oct 2003 11:22 PM
2 REAL Да черт с теми, кто спросит что ему за это будет. ИМХО, мы и так дивизию выставить можем :) По моим наблюдениям, 70% готовы на "отдачу долгов", 25% не хотят, а 5% уже делают. Что до западных университетов, то они настоящие мастера по части "эксплуатации" бывших студентов. Вот цитатка. Robert Asprin "Myth-nomers and impervections" Мифология #8 " - Более чем верно. Я подумал, может вместо стремления заставить магов говорить о потенциальных конкурентах, вам следует проверить школы. - Школы? - Разумеется. Знаете, места, где этих чарострелов обучают их ремеслу. У них должны храниться какие-то сведения, показывающие, кто чему научился. И всего скорее они поделятся с вами, поскольку вы им не конкурент. Это имело смысл, но казалось чересчур легким. - Даже если все так, то, думаешь, что они станут утруждать себя хранением адресов своих бывших студентов? - Шутишь? - рассмеялся таксист. - А как же старая Альма Матер сможет выпрашивать денежные пожертвования у своих прежних питомцев? Здесь, может, и не Дева, но неужели ты думаешь, будто изверг потеряет из виду источник дохода?"
	REAL - realkemsu.ru 29 Oct 2003 8:11 AM
"По моим наблюдениям, 70% готовы на "отдачу долгов", 25% не хотят, а 5% уже делают" Блин, здОрово :)
	Михаил Елашкин - mikeelashkin.com 29 Oct 2003 9:24 AM
Ага, здорово, но что-то организаторы в н-ске не могут организовать кворум. Может сорваться...
	Бармаглот 3 Nov 2003 11:46 AM
2ME: Не совсем в тему, но... Вот собственно и появился долгожданный результат от FSC на PrimePower 2500. Достаточно очевидно демонстрирующий в какой (_._) находится Сан и Фуджи
	Михаил Елашкин - mikeelashkin.com 11 Nov 2003 11:05 AM
2 Бармаглот Извини, долго здесь не был. А результат-то показан на 64 процессорах. А на 128? У них на предыдущей серии коэфициент масштабирования был... 0.75. Умножаем ... получаем аналогично рекорду НР. Так что как минимум не хуже. Подождем. Фуджики стреляют последними. Японцы :) А вот SAP benchmark от НР я жду...