Обсуждение
Читать и комментировать в ЖЖ ↗
Играюсь сейчас с инсталяшками OpenSolaris и FreeBSD. Они поддерживают замечательную операционную систему ZFS (Zettabyte File System). Причём, ставяться на USB стик.
А в облаках проблема с применимостью. Сейчас выгоднее большой фирме делать свой кластер, а маленькой таких вычислительных мощностей не нужно. Прыгающие же нагрузки мало у кого бывают.
Комментарий
И при все этом я (вслед за Аланом Кеем) имею наглость утверждать, что компьютерная революция еще не началась: все помянутое обеспечение многослойно и в силу этого неэффективно дублирует друг друга, основано на допотопных процессорных и сетевых архитектурах, некомпактно из-за использования нынешних языков.
Не началась. Это все клей, который связывает железо, выполненное во все той же старой парадигме. Конечно всякие хабубы/вирутализации повышают эффективность использования железа в разы, но резервы повышения на 2-3 порядка все равно есть.
Для начала надо выкинуть Виндоуз (и Линукс) - сразу требования к ресурсом снизяться, и на чип можно запихать пару сотен серверов. Если еще юзать адекватные процессорные архитектуры - то тоже возможен рост на 1.5-2 порядка, например можно прикинуть по аналогии с ФПГА, на которых задача часто ускоряется в 30-100 раз (ну или те же ГПГПУ).
Комментарий
Прыгающие нагрузки - обычное дело.
Ибо народ обычно работает в рабочее время, оно сервера и нагружает, остальное время все простаивает.
Есть еще неожиданные пиковые нагрузки, которым подверженны все, у кого сервера выходят в интернет.
Например у Голдман Сакса в августе 2007го нагрузка на систему выросла в 24 раза. А смерть Майкла Джексона обрушила многие сайты.
Есть такой слэш-дот эффект: после публикации ссылки на slashdot.org куча народу ломилось на сервер и ложила его.
Так что прыгающие нагрузки - это норма жизни. Это было понятно даже в эпоху первого интернет бума, когда все стартапы старались закупиться оборудованием, чтобы выдержать внезапный наплыв посетителей - никто не хотел оставить первое впечатление о проекте в виде неработающего сайта.
Комментарий
Посетители и покупатели - группы не во всём совпадающие. В большинстве случаев оптимизация под пиковую нагрузку не оправдана.
Те, кто на слешдоте висят, висят на слешдоте. Нужны же клиенты.
Комментарий
Оправдана/не оправдана - это уже другой вопрос. Вопрос этот стоит по любому у того, кто вовлечен в глобальную экономику. А вовлечены многие, хотя бы косвенно.
К примеру, проблемы с ликвидностью в 2006 году вызвали ипотечный кризис в америке в августе 2007 года, который вызвал уже глобальный кризис в сентябре 2008 года. И все с ним так или иначе столкнулись.
Оптимизация под пиковую нагрузку не то что не оправдана - она невыгодна. Т.е. Голдман Сакс должен был содержать мощности не в 3 раза больше, а в 24 раза, т.е. на порядок больше. Даже Голдман Саксу это напряжно. Но все 5 крупнейших инвестбанков (плюс несколько коммерческих банков, страховых контор и проч фин институций) через год подверглись серьезному реформированию (т.е. рейдерскому захвату).
В частности это было связано с тем, что в время кризиса, их execution system была парализована наплывом ордеров и они и их клиенты просто не успевали продавать акции по хорошим ценам. А это очень накладно, ибо у них позиции были взяты в кредит, и убытки у них мультиплицировались. Т.е. они на самом деле, благодаря ловким операциям с отчетностью отложили кризис на следующий год просто.
Однако некоторые финансовые институты были готовы к такому повороту событий - у них были сетки, которые выдержали такой наплыв транзакций и смогли быстро раскидать их по пулам ликвидности. Понятное дело, они неплохо наварились на стрижке крупнейших инвестбанков и их клиентов.
Так что я даже не знаю, оправдана была такая перестраховка или нет. Невыгодна для бизнесов в текущей перспективе - это да, а в долгосрочной - критично для жизнеспособности. Так же можно утверждать, что обществу в целом такой кризис и такое его течение не выгодно, поэтому я считаю, что если бы сети исполнения ордеров были работоспособны под такой нагрузкой, это было бы оправданно с точки зрения и общества в целом, и финансового коммьюнити. Потому как это называется предсказуемые правила игры.
Комментарий
Проблема только в том, что ни один из предлагателей облаков сейчас не готов подписать SLA.
С другой стороны, если оптимизировать софт, железа понадобиться гораздо меньше. Я знаю проекты, которые на одном сервере с Перлом делали быстрее и лучше то, для чего другим фирмам нужен был маленький кластер сановских машин.
Комментарий
Ну для оптимизации софта простор несомненно широкий. У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями.
Хотя кому-то удобнее Амазон облако. К примеру, если контрагент тоже в облаке, то между ними трафик будет бесплатным, чем некоторые пользуются, у тех у кого интенсивный информационный обмен. А так как активность опять же циклическая, в рабочие часы в основном, то почасовая аренда выгодна.
Комментарий
На амазоновской лекции мужик привёл знаменитую цитату Таненбаума о том, что не надо недооценивать полосу пропускания грузовика, набитого носителями. Короче, они читают себе в облако информацию, на носителе им присланную.
Комментарий
Грузовик набитый ДВДюками - это хорошо, но у него велика латентность. Иногда это важно.
Я не скажу, что Амазон облако это всегда гуд, но встречал пару проектов, где оно использовалось и там это было хорошей идеей.
Я и сам подумываю. К примеру, у меня есть одна идея-проект, там есть интенсивная вычислительная часть, пропорциональная юзерской нагрузке. Самому содержать ферму серваков неохота, а ускорить я конечно ускорю, но все равно считать много надо.
Комментарий
Смотрел на Амазон. По их ценам ферма серваков всё-таки проще. Тем более, что услугу хостинга без облаков предоставляют многие.
Комментарий
Да ценник дороговатый у них.
Комментарий
Хотя я и не сторонник параллельности
в cloud computing важны не столько параллельные вычисления, сколько scale-free и self-healing properties, типа "загрузка кластера близка к предельной? возьмём из пула ещё сотню виртуальных машин. упал контроллер? сразу взамен поднялся на другой машине". по крайней мере, это то, на что я стараюсь акцент делать.
Комментарий
У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями
ай, маладэц.
из этого следует, кстати, что любой софт можно ускорить в бесконечное число раз маленькими усилиями.
Комментарий
Очень странная история. Когда-то давным-давно было выяснено, что основная причина беспорядков на фондовых рынков -- это как раз перегрузка систем исполнения сделок. И тогда Комиссия потребовала от всех трейдерских систем выдерживание семикратной нагрузки по сравнению с их средней нагрузкой. Воплей было тогда много, но все подчинились, а вскоре какой-то мелкий кризис доказал правоту Комиссии и все заткнулись. Я думал, что обязательное требование по запасу мощности систем заказа-исполнения сделок сохранилось. Странно слышать, что мощностей не хватило в этот раз.
Комментарий
Это революция по скорости и памяти. А я еще имею ввиду революцию и по приложениям и методам их создания.
Комментарий
Ну дык что в 24 раза больше будет транзакций, никто не ожидал. Говорят, кол-во серваков срочно удвоили и это не помогло.
Кредитное плечо ведь возросло, инвестбанки наэммитировали производных в районе 10 трлн, что сравнимо с кредитной эмиссией. И потом вся эта масса в один момент стала сдуваться.
Комментарий
Не следует. Потому как кол-во переходит в качество, и сумма маленьких усилий может оказаться уже не маленькой.
ЗЫ Разумеется этот мой тезис формально неверен, и легко опровергается. Только непонятно зачем его опровергать :)
Комментарий
ЗЗЫ Есть такая теорема, что любой алгоритм можно ускорить в некотором смысле (преобразовать так, чтобы делал меньше шагов асимптотически).
Комментарий
История действительно очень странная, я пока проследил до 2006 года.
Тогда закончился срок правления Гринспена, появилась биржа ICE, торги нефтью на которой проходили в Лондоне, и американские трейдеры перестали отчитываться по крупным нефтянным фьючерсным позициям в CFTC.
Также было два интересных события, американская аккаунтинговая комиссия велела (если не ошибаюсь в сентябре 2007го, как раз после ипотечного кризиса) всем считать активы по принципу mark-to-market (до этого был mark-to estimate), а потом снова разрешила шире применять mark-to-estimate (осенью 2008го).
Также было интересно почитать Term Sheets по тем префферед стокам, которые гос-во выдавала Ситигруп. История с Мэйдоффом тоже очень интересное.
Вобщем там копать и копать, материалов даже в интернете много интересных есть.
Комментарий
Тут есть синергетический эффект, кол-во переходит в качество. Если выкинуть "окошки" с сервера (а зачем на сервере окошки??), то то что останется влезет на чип несколько раз.