Облако это аренда сервиса, когда за оборудование и обслуживание отвечает поставщик. Самое банальное — gmail.

Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании, специалисты стали слишком дороги для найма, при этом скорость и доступность интернета позволила передать многие производственные процессы внешним поставщикам. Ну и какая-то доля моды, не без этого. Но в целом ничего особенного тут нет, это и вне IT происходит везде. Мелкий магазин не будет нанимать курьеров, ему дешевле сотрудничать с курьерской службой, самый банальный пример. Или бухгалтерию отдать на ведение специализированной фирме, которая обслуживает кучу таких магазинов. По сути это банальная специализация.

Была файлопомойка — стало owncloud. Звучит солидно.
А всякие сетевые хранилища еще Sun продвигала с начала-середины 80-х, NFS изобрела. Всякие там rcp и scp для синхронизаций тоже придумали в районе второй половины 80-х. В середине 90-х, была попытка Oracle внедрить Net PC, правда большого успеха она не имела, хотя и прижилась кое-где в учреждениях. Всякие там VPN и виртуальные хосты — это тоже совсем, совсем не новое, местами так даже из 1960-х годов.

И вдруг в 2010-х прорвало: Cloud, WoW!

Здравствуйте, DOOM, Вы писали:

DOO>Может даже расчеты готов привести?

Я уже спрашивал про твои расчеты.
Где они?

DOO>некоторые облачные сервисы по TCO в разрезе 5 лет выигрывают на порядки.

Здравствуйте, Yoriсk, Вы писали:

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

Здравствуйте, Anton Batenev, Вы писали:

НС>> НС>> В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.
НС>> AB>А уместить эти ресурсы в рамки одного инстанса этого самого облака?
НС>> А на Луну слетать? К чему этот вопрос?

AB>К тому, что ты не можешь заказать столько ресурсов, сколько тебе нужно — облачная нода, как и мэйнфрейм, точно так же ограничена железом.

Я могу заказать столько нод, сколько мне нужно.

Здравствуйте, DOOM, Вы писали:

DOO>У меня вот есть внутренний анализ от отдела эксплуатации по стоимости хранения резервных копий — некоторые облачные сервисы по TCO в разрезе 5 лет выигрывают на порядки. Даже ленточки, которые всегда были самым дешевым носителем!

это если у вас тяп-ляп стартап с временем жизни менее года.

у меня ленточки бесплатно хранятся в трех экземплярах в разных географических регионах, резервируя от попадания метеорита в одной локации и нападения годзилл в другой. считается мало вероятно что одновременно с этими событиями в третьей случится чОрная дыра.

ваше облако в какой степени защищает от этих угроз? что будет если ВНЕЗАПНО вам потребуется резервная копия а связь с вашим облаком будет невозможна?

какой глубины архив в вашем облаке?

возьмем мой случай. ленточка LTO-5 вмещает в себя 3 ТБ.

у меня ленточки бесплатно хранят ежедневный (366х1=370), еженедельный (54х3=170) и ежегодный (12х5=60) архивы. это покрывает 5 лет архива.

и так. для борьбы на равных с облаком возьмем одну локацию.

в одной локации 600 ленточек по $10 + два привода по $2000.
$10 000 на 5 лет.
$2000 в год.
$166 в месяц за хранение 1800 ТБ. почти два петабайта.

сколько вам облако за хранение (пусть даже и половины) петабайта приплачивает?

интернет на всем пути от вас до облака, соточка я надеюсь? сколько времени вы будете восстанавливать из архива?

Все проблемы от жадности и глупости

Здравствуйте, Michael7, Вы писали:

M>Была файлопомойка — стало owncloud. Звучит солидно.
M>А всякие сетевые хранилища еще Sun продвигала с начала-середины 80-х

Sun уже действовала на пути удешевления того, что сейчас величают cloud-ами, и представленного
до Sun-ов в виде IBM-овских майнфреймов. Первыми cloud-ами были те самые майнфреймы, более того,
тогда это было единственной формой организации вычислений.

Здравствуйте, Michael7, Вы писали:

M>И вдруг в 2010-х прорвало: Cloud, WoW!
Потому что это, скорее, не технология, а бизнес-модель.
Хотя и доля технологии тут есть — без такой развитой виртуализации, которую мы получили в середине нулевых облака, такие как они есть сейчас, были бы невозможны.
А так — модель SaaS, особенно для частных лиц, существуюет достаточно давно.
IaaS — более новый вариант, сейчас тоже стал нормой (сейчас уже мало кто заморачивается коллокейшеном, который процветал в конце 90-ых, например).
Ну а последние годы и PaaS активно форсится, хотя, ИМХО, все равно остается очень нишевым.

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

Здравствуйте, vsb, Вы писали:

vsb>Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании, специалисты стали слишком дороги для найма,

Наоборот. локальное оборудование стало дешевым и доступным. А специалисты всегда были дорогие.

Все проблемы от жадности и глупости

vsb>>Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании

C>Покупка железа окупит себя меньше чем за год, по сравнению с облаком.

Ну вот были знакомые чуваки, делали типа Disqus'а. Их продукт использовался на всяких мелких сайтах типа New York Times и официальный сайт Lady Gaga. Любая новость на сайте Гаги могла внезапно поднять трафик с 10 сообщений в секунду до пары сотен тысяч в секунду.

В их случае они просто поднимали новые инстансы на Амазоне. Что ты будешь делать со своим железом?

Здравствуйте, consign, Вы писали:

C>Это всё я уже учел, с очень щедрыми допусками.
C>Если ты гоняешь железо 24 часа в сутки и не учитываешь ремонт и обслуживание, оно окупается вообще за 3 месяца, по сравнению с EC2.
Ну позволю себе не поверить. Либо ты считал какие-то непонятные ноунеймы, либо что.


C>Как показала практика, гарантии Amazon тоже мало чего стоят.
100% доступности не обеспечит никто, НО у амазона доступность их сервиса выше на порядки, чем у доморощенного.

Здравствуйте, Michael7, Вы писали:

M> Была файлопомойка — стало owncloud. Звучит солидно.

Да, термин "облака" — это чистый маркетинг.

Здравствуйте, DOOM, Вы писали:

DOO>У меня вот есть внутренний анализ от отдела эксплуатации по стоимости хранения резервных копий — некоторые облачные сервисы по TCO в разрезе 5 лет выигрывают на порядки. Даже ленточки, которые всегда были самым дешевым носителем!

Ну вот, кстати, показали бы цифири и разговор внезапно стал бы предметным и по делу.

Здравствуйте, DOOM, Вы писали:

DOO>Ну просто цифири тоже никого не устроят

Устроят, если они разумные.

Здравствуйте, Mamut, Вы писали:

M>Позволь мне напомнить вопрос, на который ты так и не ответил:
M>

M>В их случае они просто поднимали новые инстансы на Амазоне. Что ты будешь делать со своим железом?

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

Здравствуйте, DOOM, Вы писали:

Y>>Ну вот, кстати, показали бы цифири и разговор внезапно стал бы предметным и по делу.
DOO>Ну просто цифири тоже никого не устроят

Более чем.

DOO>а показывать подробный расчет я не имею права, естественно.

Ну конечно, совершенно внезапно оказалось, что прикидочный расчёт — это стрррашная коммерческая тайна, NDA и прочие ужасные акронимы.

Здравствуйте, Stanislaw K, Вы писали:

SK>Здравствуйте, DOOM, Вы писали:

SK>>>у меня ленточки бесплатно хранятся
DOO>>Что значит "бесплатно"? Помещение не стоит денег?
SK>Не стоит. помещение уже есть.

оно все равно стоит денег. Даже если есть. Даже если в собственности.
Даже если на своей земле.


SK>>>в трех экземплярах в разных географических регионах,
DOO>>Значит тоже нужны каналы связи. Если это разные регионы, то сильно сомневаюсь, что канал свой. А если свой, то там такие кап. затраты и операционные затраты, что дальше можно не считать.
SK>А до "облака" канал связи стало быть уже и не нужен?
не передергивай. В своем расчете ты их исключаешь, а в облаке требуешь учесть.

DOO>>Опять-таки, организаций которым нужна регионально-распределенная катастрофоустойчивость тоже крайне мало.
SK>Ну, не скажи, не скажи...
Скажу. Реально от ИТ так сильно зависят только телеком и банки. Банки чаще всего обходятся локальной катастрофоучтойчивостью.

DOO>>Что такое бесплатно хранят? Ленточки летят, их надо периодически проверять, заменять, привод обслуживать и т.п. Если вы не умеете считать расходы, это не значит, что их нет.
SK>У меня за все время "полетело" две ленточки. В расчетах сделан запас на это. Периодически проверять нужно любой архив. Привод обслуживать конечно надо. но это копеечные затраты. входящие в стоимость носителя.
Да неверно это. Тебе как минимум надо нанять человека, который будет заниматься заменой и учетом ленточек. При таком количестве ленточек (и отсутствии библиотеки-робота) это уже не копеечные затраты.
Да и вообще странно — считать самое Low end оборудование при таких объемах и требованиях по катастрофоучтойчивости
Насчет ленточек — у меня есть статистика другая. Кому как везет.

SK>Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.
Да ладно... вот гугл меня сидит и обманывает...

DOO>>То же HP по самой грубой прикидке дороже в 2 раза (по приводам больше).
SK>Ты смотришь розничные цены, для домашних пользователей со штучными покупками. Как только ты придешь к дилеру HP и скажешь что и сколько ты хочешь, цены становятся значительно интереснее.
Я смотрю, так называемый, Internet price, который в РФ ты никогда не увидишь даже для самой большой партии, потому что НДС, растаможка, другие налоги, маржа и пр.
Уровень спеццен HP, поверь, я знаю.
А по приводам — 5к баксов стоит банальный автолоадер с магазином на 8 кассет.

DOO>>И сколько ты платишь тому, кто ручками постоянно меняет ленточки в приводах? Это ж не роботы у тебя по 2000 баксов-то...

SK>младший админ раз в день уделяет 10 минут на замену ленточки. раз в неделю он бросает монетку и проверяет случайную ленту из предыдущих бэкапов на читаемость в принципе, на целостность архива и возможность восстановить. Это полуавтоматический процесс. Ручного там только сменить ленту и нажать несколько кнопок в консоли. Не так уж и трудно оторваться от контры на пол часа.
Сколько он еще успеет накосячить по дороге? И главное — этот человек у тебя все равно есть и несешь на него затраты.

DOO>>И сколько ты будешь проводить восстановление в своей мега системе, когда надо ручками разобраться с твоими шестью сотнями ленточек?
SK>На каждой ленточке всё подписано. "день 240" "Неделя 31" "Год 2014 часть 2" Что там разбираться?
И их 600 одной стопкой стоит? Меня удивляет, что при реально огромном объеме данных и совершенно странных требованиях по глубине архива (ну кому надо иметь слепок за каждый день на год назад???) ты предлагаешь использовать какой-то костыльно-ручной метод организации системы хранения...
К слову, дедупликацию смотреть не пробовал? Что-то мне подсказывает, что дисковая система с дедупликацией, в твоем случае, сильно снизит объемы, да и, возможно, стоимость.

SK>>>$10 000 на 5 лет.
SK>>>$2000 в год.
SK>>>$166 в месяц за хранение 1800 ТБ. почти два петабайта.
DOO>>Красиво, но посчитано некорректно.
SK>Не вопрос. Покажи свои расчеты.
+ затраты на помещение. Можно даже пропорционально месту, которое занимают ленточки и приводы.
+ затраты на админа (или кого угодно), кто обслуживает систему
+ ЗИП, затраты на ремонт и пр.
+ риски потери данных (надо отдельно оценивать)
+ затраты на апгрейд как-то надо размазать (частично можно в текущий ремонт запихать, но все же)
+ электричество на работу приводов, затраты на кондиционирование (благо на привод копейки, но все же) и прочий микроклимат серверного помещения
и т.п. (это я только сходу вспомнил — если посмотреть труды тех же APC или VMware, то у них еще можно статей расхода натягать).

SK>>>сколько вам облако за хранение (пусть даже и половины) петабайта приплачивает?
DOO>>Пол петабайта, к слову, интересное число, потому что есть фиксированные тарифные планы на 500 Tb — порядка 30 баксов в месяц (!)
DOO>>А так, цена примерно на уровне 0.5 цента за 1 Gb в месяц. Если считать по-честному (см. выше), то получится выгоднее местами.

SK>у меня как раз все понятно. мне они не нужны. реплика между площадками делается всегда автоматически. при канале 10 мегабит в пике занимает полосу до 2. все остальное на нужды офиса.
Ииии? В чем проблема если примерно то же будет организовано у меня с облаком?

К слову, у амазона есть еще интересный сервис — Glacier. Там 3 Tb уже тупо дешевле ленточки стоят (ну, если смотреть ее реальную стоимость, а не 10 баксов, взятые непонятно откуда). Учитывая, как у тебя устроен архив, сравнивать с таким сервисом корректнее, так как обычный облачный сторедж — это почти онлайн доступ.
Единственный минус — тут реально одна площадка.

Здравствуйте, Stanislaw K, Вы писали:

SK>Здравствуйте, DOOM, Вы писали:

SK>Оно есть и на него тратятся деньги независимо от того, лежат там ленточки или швабры стоят. Очевидно размещение ленточек полезнее чем швабр.
Это у тебя так. Во многих организациях площади на вес золота. Реально.

SK>в своем расчете я исключил потому, что рассматривал только одно хранилище. если бы я включил в расчеты удаленные локации, я бы посчитал и каналы связи.
Ок. Эту твою мысль понял.

DOO>>>>Опять-таки, организаций которым нужна регионально-распределенная катастрофоустойчивость тоже крайне мало.
SK>>>Ну, не скажи, не скажи...
DOO>>Скажу. Реально от ИТ так сильно зависят только телеком и банки. Банки чаще всего обходятся локальной катастрофоучтойчивостью.

SK>медицина. наука.
хз. С ними не работал. Но, зная зарегулированность медицины, сильно сомневаюсь.
SK>финансы.
Кроме банков что ты туда включил? Одну-две биржи в стране?

SK>производство.
Неверно. Чихать они хотели на ИТ. В прямом смысле. Отсутствие ЗИП, контрактов сопровождения даже на критичное оборудование там норма.
Да, когда инцидент реально происходит, кто-то репу чешет, но завод не встанет — это ключевое, поэтому и пофиг всем.

SK>и пожалуй все что крупнее 100 миллионов в год. я сразу сказал "НЕ тяп-ляп стартап".
Нет, не верно. Я знаю немало банков, которые до сих пор не смогли согласовать у руководства строительство резервного ЦОД. А оборот даже самого крохотного банка куда больше 100 млн. при том, что от ИТ они зависят на 100%.

SK>и кстати да. катастроф-устойчивые удаленные локации — это не обязательно еще один офис с комплектом оборудования. это может быть сейф в банке, куда ленточки завозятся курьером.
Это не катастрофоустойтивость, если что. RTO у тебя будет сколько, если ничего, кроме ленточки на руках? Зачем тогда такое безумное RPO?
Хотя не суть, конечно.

SK>>>Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.
DOO>>Да ладно... вот гугл меня сидит и обманывает...
SK>Он не обманывает. он про это не говорит. ты сам себе придумал и веришь.
Почитай описание именно Enterprise варианта — ничего я не придумываю.
Не надо ориентироваться на всякие гугл драйв для обычных юзеров...

DOO>>Сколько он еще успеет накосячить по дороге? И главное — этот человек у тебя все равно есть и несешь на него затраты.
SK>Вот именно. Если я перенесу хранилище в облако этот человек, его косяки и затраты на него у меня все равно останутся.
Ну ты усиленно рассматриваешь локальную оптимизации, в условиях, что большую часть затрат уже понес, а значит пофиг — это неверно.


DOO>>+ затраты на помещение. Можно даже пропорционально месту, которое занимают ленточки и приводы.
SK>оно есть. и в том и в другом случае.
см. выше

DOO>>+ затраты на админа (или кого угодно), кто обслуживает систему
SK>оно есть. и в том и в другом случае.
см. выше

DOO>>+ ЗИП, затраты на ремонт и пр.
SK>ЗИП — ленточки куплены с запасом. два привода для резервирования. пятилетний гарантийный ремонт входит в стоимость контракта на покупку. раз в год приезжает специальный человек для профилактики, протирает пыль, смазывает узлы и еще что то делает.
5 лет гарантии + ТО за 2 штуки баксов???? Это что за вендор?

DOO>>+ риски потери данных (надо отдельно оценивать)
SK>оно есть. и в том и в другом случае.
Да. Но в случае облака перед тобой несут финансовую ответственность за потери (что, конечно, выражается в том, что за косяк тебе просто простят какую-то сумму оплаты, а не дадут реальные деньги).
В твоем случае этого нет и надо закладывать какие-то доп. затраты на компенсацию риска.

DOO>>+ затраты на апгрейд как-то надо размазать (частично можно в текущий ремонт запихать, но все же)
SK>оно есть. и в том и в другом случае.
? Где? В облаке я получаю сервис, мне не надо заморачиваться за замену устаревшего оборудования, так как я даже не знаю про его существование.

DOO>>+ электричество на работу приводов, затраты на кондиционирование (благо на привод копейки, но все же) и прочий микроклимат серверного помещения
SK>оно есть. и в том и в другом случае.
Тут я что-то тем более не понял...

SK>Это не расчеты. Это туманный ответ на вопрос "почему я не хочу так делать".
SK>Ты хотя бы на салфетке эскиз расчетов набросай, как это сделал я.
Честно — лень. Всех этих расчетов в интернете куча. Есть даже не чистый маркетинг, а вполне реальные кейсы.
Твой кейс тоже притянут за уши — не бывает объемов в 2 петабайта, которые бэкапятся одним лоу-энд приводом. Ни перед каким бизнесом таких задач не стоит. Если это у тебя реальная задача, то это очень экзотический вариант, который ты пытаешься выдать за норму.
Если уж что-то считать, то реальное.
Соответственно, у нас либо получится, что есть один сервак с системой, с которого надо снимать по 300-400 Гб резервной копии в день и хранить, ну, максимум, неделю по дням + месяц по неделе (что уже другие объемы и стоимость привода перевешивает все).
Либо будет здоровый ЦОД, где надо ежедневно бэкапить десятки или сотни терабайт, но там уже будет совсем другая система, потому что один вшивый привод не осилит это и за неделю. Там тоже своя арифметика будет.

DOO>>Ииии? В чем проблема если примерно то же будет организовано у меня с облаком?
SK>В том, что когда тебе внезапно потребуется восстановить данные, в облаке может не оказаться электричества.
Это из области фантастики. Примерно как с тем, что накроет все твои 3 места хранения копий.

SK>Или связь с облаком будет плохой.
С какой стороны? Если с твоей — то да, надо озаботиться надежным каналом. Это все понимают и это, благо, давно уже не проблема. Например, у нас на работе 3 интернет провайдера и минимум, до которого может деградировать сервис — 20 Мб/с.
Со стороны облака — тоже из области фантастики. Представляю себе, как пропал интернет у облака Ростелекома того же...

SK>Или связи не будет по политическим соображениям санкций...
SK>Ты в своих "расчетах" забыл политику.
Политику я не смотрел. Тогда еще надо учесть, что ряд компаний, по политическим причинам, предпочитают данные в РФ не хранить, что не учел уже ты...
Но есть и отечественные решения — просто у нас ценник, мягко говоря, другой и сервис не так развит.

DOO>>К слову, у амазона есть еще интересный сервис — Glacier. Там 3 Tb уже тупо дешевле ленточки стоят (ну, если смотреть ее реальную стоимость, а не 10 баксов, взятые непонятно откуда). Учитывая, как у тебя устроен архив, сравнивать с таким сервисом корректнее, так как обычный облачный сторедж — это почти онлайн доступ.
DOO>>Единственный минус — тут реально одна площадка.
SK>О том и речь.
Можно сделать 2. Причем будет, скорее всего, не тупо в 2 раза дороже.

SK>Да. Облако тебе какой SLA предлагает? Сколько суток они будут тикет рассматривать?
Суток? Нафига мне такой вариант? SLA все прописаны — смотри, выбирай.
Я опять повторю: ты смотри не TOS для обычного юзера, а то, что эти сервисы предлагаю энтерпрайзу: там договора, ответственность, четкий SLA, компенсации за косяки и пр.

Здравствуйте, smeeld, Вы писали:

S>Sun уже действовала на пути удешевления того, что сейчас величают cloud-ами, и представленного
S>до Sun-ов в виде IBM-овских майнфреймов. Первыми cloud-ами были те самые майнфреймы, более того,
S>тогда это было единственной формой организации вычислений.

Не были они облаками. Неотъемлемый признак облака — динамеческое распределение ресурсов большой кластерной сети. А мейнфрейм — он мейнфрейм и есть.

Здравствуйте, smeeld, Вы писали:

S>Вы точно знаете что такое майнфрейм, и читали спеки по его эксплуатации, обслуживанию? Ресурсы любого майнфрейма прежде
S>всего разбиваются на части, которые по отдельности используются.

Точно знаю. А ты точно знаешь что такое облако? В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно. А мейнфрейм это фиксированная аппаратура, проапгрейдить которую ты можешь только сменой физического железа, да и то до определенных пределов.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Точно знаю. А ты точно знаешь что такое облако? В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.

Тоже самое в майнфрейме, или забыли как в те времена торговали количеством процессорных ресурсов, памяти?
Это несколько иначе, чем в современных облаках, но это только в деталях, в принципе всё то же самое.

> А мейнфрейм это фиксированная аппаратура, проапгрейдить которую ты можешь только сменой физического железа, да и то до определенных пределов.

Не только сменой, ресурсы можно наращивать, причём "в горячую", что есть большой OK для для задач финансовой
сферы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Не то же самое. Сколько железа у тебя в мейнфрейме есть, столько и есть, и больше не будет, как ты не виртуализуй.

В кластерах тоже наращивание ограничено в некотором смысле. Когда кто-то заказывает много ресурсов, то
отдельные части заказанного оказываются расположенными на разных нодах кластера. Для некоторых задач,
вроде исполнения ERP, это приведёт к тому, что исполнение задач в облаке будет жутко тормозить.
Именно поэтому многопроцессорные шкафы до сих пор живы и здоровы, а кластерные облака в основном
используются только для хорошо параллелящихся задач, и в основном, их клиентами являются мелкая рыбёшка
с задачками постинга котиков в инете.

Здравствуйте, smeeld, Вы писали:

S>Тоже самое в майнфрейме, или забыли как в те времена торговали количеством процессорных ресурсов, памяти?
Нет, не забыли. Там торговали машинным временем на фиксированной машине. Если нужно было больше, чем на машине железа — упс.

S>Не только сменой, ресурсы можно наращивать, причём "в горячую", что есть большой OK для для задач финансовой
S>сферы.
Не более пределов масштабируемости железа. Причём они совершенно смешные по нынешним облачным меркам.

Например, я могу парой кликов запустить кластер из 5 тысяч процессоров по цене около $100 в час. Сколько там стоит mainframe с такой вместительностью?

Здравствуйте, DOOM, Вы писали:

DOO>Что за привычка попытаться выдумать искусственный нежизненный пример и потом начать им размахивать со словами "говно ваши облака — вот это не могут".
DOO>Особенно смешно выглядит, когда тебе в соседнем же сообщении показывают, что не все так плохо, как ты себе представляешь.

DOO>Но надо, блин, вспоминать мхом поросшие мэйнфреймы с периодом окупаемости десятки лет, при том, что модель 3-4-х летней давности в полном фарше проигрывает по всем показателям парочке "обычных" современных x86-х серверов, которые хоть каждый год обновляй (но еще лучше не париться и взять облачный сервис).

Вы вот так говорите, потому-что ничего сложнее задач постинга котиков в инете и PC-шных
свистелок-перделок для юзера в глаза не видели, но мнение имеете.

Здравствуйте, vsb, Вы писали:

vsb>Облако это аренда сервиса, когда за оборудование и обслуживание отвечает поставщик. Самое банальное — gmail.

Так я о том, что такие аренды и сервисы существовали еще в 90-х как-минимум. Не возникло какой-то новой технологии, которую потребовалось назвать новым словом. Более того, слово облако — нечеткое, как и реальное облако, в каждом отдельном случае без дополнительного уточнения не вполне ясно о чем конкретно речь идет.

vsb>Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании, специалисты стали слишком дороги для найма, при этом скорость и доступность интернета позволила передать многие производственные процессы внешним поставщикам.

Сдается мне, задач которые слишком дорого решать на локальном оборудовании не так и много, среди прочих. Тут больше идея контроля за пользователями и ограничение распространения информации или каких-то технологий. Например, сервис распознавания речи не требует очень больших ресурсов и может быть для смартфона их маловато, но уж для настольного компьютера точно более чем достаточно. А может даже и для смартфона уже достаточно, было бы желание. Понапихали ведь в них 4-х ядерные процессоры (хотя и не x86) уже и сотни мегабайт памяти. Не хватает процессора, так какой-нибудь voice-chip специализированный вполне мог бы справиться думаю. Распознавать речь, не очень хорошо, но умела еще OS/2 в 90-х на смешном по современным меркам оборудовании.

Но ведь как заманчиво для всех слушать пользователя, притом с его же согласия и за его деньги. И технологию не надо отчуждать даже в виде бинарников.

vsb> Ну и какая-то доля моды, не без этого. Но в целом ничего особенного тут нет, это и вне IT происходит везде. Мелкий магазин не будет нанимать курьеров, ему дешевле сотрудничать с курьерской службой, самый банальный пример. Или бухгалтерию отдать на ведение специализированной фирме, которая обслуживает кучу таких магазинов. По сути это банальная специализация.

Ну да, и она всегда была.

Здравствуйте, smeeld, Вы писали:

S>Sun уже действовала на пути удешевления того, что сейчас величают cloud-ами, и представленного
S>до Sun-ов в виде IBM-овских майнфреймов. Первыми cloud-ами были те самые майнфреймы, более того,
S>тогда это было единственной формой организации вычислений.

Собственно да. Согласен. И элементы этой технологии появились еще в 60-е годы.

Здравствуйте, vsb, Вы писали:

vsb>Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании

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

Здравствуйте, Mamut, Вы писали:

M>Любая новость на сайте Гаги могла внезапно поднять трафик с 10 сообщений в секунду до пары сотен тысяч в секунду.

То есть речь о пиковых нагрузках, которые длятся максимум часы.

Здравствуйте, consign, Вы писали:

C>Покупка железа окупит себя меньше чем за год, по сравнению с облаком.
А про TCO ты слышал?
Даже если не будешь брать вендорские договоры поддержки, то придется вкладываться в ЗИП — оборудование ломается так-то.
Я уж молчу о том, что помимо оборудования ты можешь получать еще какой-нибудь неочевидный сервис — типа гарантированного доступа в Интернет, что на своей площадке реализовать крайне непросто и затратно (именно поэтому уже давно никто не парится с размещением на своей территории web сервера компании).

Здравствуйте, consign, Вы писали:

c> M>Любая новость на сайте Гаги могла внезапно поднять трафик с 10 сообщений в секунду до пары сотен тысяч в секунду.
c> То есть речь о пиковых нагрузках, которые длятся максимум часы.
Думаю, если бы они эти часы лежали, то потеряли бы клиентов. Так что или держать постоянно "лишнее" железо или подключать облака по мере необходимости.

Здравствуйте, DOOM, Вы писали:

DOO>А про TCO ты слышал?
DOO>Даже если не будешь брать вендорские договоры поддержки, то придется вкладываться в ЗИП — оборудование ломается так-то.

Это всё я уже учел, с очень щедрыми допусками.
Если ты гоняешь железо 24 часа в сутки и не учитываешь ремонт и обслуживание, оно окупается вообще за 3 месяца, по сравнению с EC2.

DOO>Я уж молчу о том, что помимо оборудования ты можешь получать еще какой-нибудь неочевидный сервис — типа гарантированного доступа в Интернет, что на своей площадке реализовать крайне непросто и затратно (именно поэтому уже давно никто не парится с размещением на своей территории web сервера компании).

Как показала практика, гарантии Amazon тоже мало чего стоят.

Здравствуйте, vsb, Вы писали:

vsb>Прорвало, потому что многие задачи стали слишком дорого решать на локальном оборудовании, специалисты стали слишком дороги для найма, при этом скорость и доступность интернета позволила передать многие производственные процессы внешним поставщикам.

Открой для себя Мейнфреймы. 70-е годы, да. Единая серия.

M>>Любая новость на сайте Гаги могла внезапно поднять трафик с 10 сообщений в секунду до пары сотен тысяч в секунду.
C>То есть речь о пиковых нагрузках, которые длятся максимум часы.

И?

Здравствуйте, alpha21264, Вы писали:

A>Открой для себя Мейнфреймы. 70-е годы, да. Единая серия.
Ииии? Высокая стоимость, низкая масштабируемость. Ограниченная модель "pay as you grow" (только в одну сторону — арендовать доп. процессор на месяц нельзя).
Причем ROI у них чуть ли не десятки лет, при том, что тот же HP Superdome уделает пара современных блейдов

Короче, гибкость ни разу ни соизмеримая. И порядок стоимости совсем другой.

Здравствуйте, DOOM, Вы писали:

DOO>Ну позволю себе не поверить. Либо ты считал какие-то непонятные ноунеймы, либо что.

Жду твоих расчетов.

DOO>100% доступности не обеспечит никто, НО у амазона доступность их сервиса выше на порядки, чем у доморощенного.


Сколько раз он уже падал?

Здравствуйте, Mamut, Вы писали:

M>И?

Для экстренной необходимости на несколько часов — имеет смысл. И только.

Здравствуйте, consign, Вы писали:

C>Для экстренной необходимости на несколько часов — имеет смысл. И только.
Может даже расчеты готов привести?
У меня вот есть внутренний анализ от отдела эксплуатации по стоимости хранения резервных копий — некоторые облачные сервисы по TCO в разрезе 5 лет выигрывают на порядки. Даже ленточки, которые всегда были самым дешевым носителем!

Здравствуйте, Michael7, Вы писали:

M>Была файлопомойка — стало owncloud. Звучит солидно.
Ну вообще-то, owncloud ещё умеет синхронизацию контактов, почты, календарей. Файлопомойки такого не умеют.

M>Всякие там VPN и виртуальные хосты — это тоже совсем, совсем не новое, местами так даже из 1960-х годов.
M>И вдруг в 2010-х прорвало: Cloud, WoW!
Немного уровень другой. В теории раньше был Sun с их "Computer is the network" (или наоборот?), но до середины 2000-х это всё дальше локальной сети не уходило. Только сравнительно недавно появилась возможность делать крупномасштабные гибкие датацентры для продажи времени на виртуальных машинах.

"Крупномасштабного" — это так, что не нужен выделенный админ на каждых 10 пользователей, как было раньше.

Здравствуйте, Stanislaw K, Вы писали:


SK>у меня ленточки бесплатно хранятся
Что значит "бесплатно"? Помещение не стоит денег?

SK>в трех экземплярах в разных географических регионах,
Значит тоже нужны каналы связи. Если это разные регионы, то сильно сомневаюсь, что канал свой. А если свой, то там такие кап. затраты и операционные затраты, что дальше можно не считать.

SK>ваше облако в какой степени защищает от этих угроз?
Смотри, выбирай. Их много. Добиться такого же уровня катастофоустойчивости можно.
Опять-таки, организаций которым нужна регионально-распределенная катастрофоустойчивость тоже крайне мало.

SK>что будет если ВНЕЗАПНО вам потребуется резервная копия а связь с вашим облаком будет невозможна?
У меня тот же вопрос про твои 3 хранилища
А вообще — естественно, надо обеспечить и в своем офисе нормальный выход в Интернет, и провайдера сервиса с нужной доступностью выбирать.

SK>какой глубины архив в вашем облаке?
в данном случае неважно, так как облако рассматривалось как хранилище, а не как сервис резервного копирования.

SK>возьмем мой случай. ленточка LTO-5 вмещает в себя 3 ТБ.
SK>у меня ленточки бесплатно хранят ежедневный (366х1=370), еженедельный (54х3=170) и ежегодный (12х5=60) архивы. это покрывает 5 лет архива.
Что такое бесплатно хранят? Ленточки летят, их надо периодически проверять, заменять, привод обслуживать и т.п. Если вы не умеете считать расходы, это не значит, что их нет.

SK>и так. для борьбы на равных с облаком возьмем одну локацию.
Облако почти всегда много локаций — так что это будет не на равных как раз.

SK>в одной локации 600 ленточек по $10 + два привода по $2000.
Ленточки по 10, приводы по 2000 — это что за оборудование?
То же HP по самой грубой прикидке дороже в 2 раза (по приводам больше).
И сколько ты платишь тому, кто ручками постоянно меняет ленточки в приводах? Это ж не роботы у тебя по 2000 баксов-то...
И сколько ты будешь проводить восстановление в своей мега системе, когда надо ручками разобраться с твоими шестью сотнями ленточек?

SK>$10 000 на 5 лет.
SK>$2000 в год.
SK>$166 в месяц за хранение 1800 ТБ. почти два петабайта.
Красиво, но посчитано некорректно.

SK>сколько вам облако за хранение (пусть даже и половины) петабайта приплачивает?
Пол петабайта, к слову, интересное число, потому что есть фиксированные тарифные планы на 500 Tb — порядка 30 баксов в месяц (!)
А так, цена примерно на уровне 0.5 цента за 1 Gb в месяц. Если считать по-честному (см. выше), то получится выгоднее местами.

SK>интернет на всем пути от вас до облака, соточка я надеюсь? сколько времени вы будете восстанавливать из архива?
некорректный вопрос — у тебя тоже непонятно ничего с каналами связи.

M>>И?
C>Для экстренной необходимости на несколько часов — имеет смысл. И только.

Позволь мне напомнить вопрос, на который ты так и не ответил:

В их случае они просто поднимали новые инстансы на Амазоне. Что ты будешь делать со своим железом?

Здравствуйте, DOOM, Вы писали:

SK>>у меня ленточки бесплатно хранятся
DOO>Что значит "бесплатно"? Помещение не стоит денег?

Не стоит. помещение уже есть.

SK>>в трех экземплярах в разных географических регионах,
DOO>Значит тоже нужны каналы связи. Если это разные регионы, то сильно сомневаюсь, что канал свой. А если свой, то там такие кап. затраты и операционные затраты, что дальше можно не считать.

А до "облака" канал связи стало быть уже и не нужен?

SK>>ваше облако в какой степени защищает от этих угроз?
DOO>Смотри, выбирай. Их много. Добиться такого же уровня катастофоустойчивости можно.
DOO>Опять-таки, организаций которым нужна регионально-распределенная катастрофоустойчивость тоже крайне мало.

Ну, не скажи, не скажи...

SK>>что будет если ВНЕЗАПНО вам потребуется резервная копия а связь с вашим облаком будет невозможна?
DOO>У меня тот же вопрос про твои 3 хранилища
DOO>А вообще — естественно, надо обеспечить и в своем офисе нормальный выход в Интернет, и провайдера сервиса с нужной доступностью выбирать.

Какого именно провайдера? Как ты это делаешь? Какие методики применяешь? Как часто или по каким событиям пересматриваешь выбор?

SK>>какой глубины архив в вашем облаке?
DOO>в данном случае неважно, так как облако рассматривалось как хранилище, а не как сервис резервного копирования.

Я надеюсь ваш внутренний анализ не рассматривал "как хранилище" компакт диски?

SK>>возьмем мой случай. ленточка LTO-5 вмещает в себя 3 ТБ.
SK>>у меня ленточки бесплатно хранят ежедневный (366х1=370), еженедельный (54х3=170) и ежегодный (12х5=60) архивы. это покрывает 5 лет архива.
DOO>Что такое бесплатно хранят? Ленточки летят, их надо периодически проверять, заменять, привод обслуживать и т.п. Если вы не умеете считать расходы, это не значит, что их нет.

У меня за все время "полетело" две ленточки. В расчетах сделан запас на это. Периодически проверять нужно любой архив. Привод обслуживать конечно надо. но это копеечные затраты. входящие в стоимость носителя.

SK>>и так. для борьбы на равных с облаком возьмем одну локацию.
DOO>Облако почти всегда много локаций — так что это будет не на равных как раз.

Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.

SK>>в одной локации 600 ленточек по $10 + два привода по $2000.
DOO>Ленточки по 10, приводы по 2000 — это что за оборудование?
DOO>То же HP по самой грубой прикидке дороже в 2 раза (по приводам больше).

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

DOO>И сколько ты платишь тому, кто ручками постоянно меняет ленточки в приводах? Это ж не роботы у тебя по 2000 баксов-то...

младший админ раз в день уделяет 10 минут на замену ленточки. раз в неделю он бросает монетку и проверяет случайную ленту из предыдущих бэкапов на читаемость в принципе, на целостность архива и возможность восстановить. Это полуавтоматический процесс. Ручного там только сменить ленту и нажать несколько кнопок в консоли. Не так уж и трудно оторваться от контры на пол часа.

DOO>И сколько ты будешь проводить восстановление в своей мега системе, когда надо ручками разобраться с твоими шестью сотнями ленточек?

На каждой ленточке всё подписано. "день 240" "Неделя 31" "Год 2014 часть 2" Что там разбираться?

SK>>$10 000 на 5 лет.
SK>>$2000 в год.
SK>>$166 в месяц за хранение 1800 ТБ. почти два петабайта.
DOO>Красиво, но посчитано некорректно.

Не вопрос. Покажи свои расчеты.

SK>>сколько вам облако за хранение (пусть даже и половины) петабайта приплачивает?
DOO>Пол петабайта, к слову, интересное число, потому что есть фиксированные тарифные планы на 500 Tb — порядка 30 баксов в месяц (!)
DOO>А так, цена примерно на уровне 0.5 цента за 1 Gb в месяц. Если считать по-честному (см. выше), то получится выгоднее местами.

SK>>интернет на всем пути от вас до облака, соточка я надеюсь? сколько времени вы будете восстанавливать из архива?
DOO>некорректный вопрос — у тебя тоже непонятно ничего с каналами связи.

у меня как раз все понятно. мне они не нужны. реплика между площадками делается всегда автоматически. при канале 10 мегабит в пике занимает полосу до 2. все остальное на нужды офиса.

Все проблемы от жадности и глупости

Здравствуйте, DOOM, Вы писали:


SK>>Не стоит. помещение уже есть.
DOO>оно все равно стоит денег. Даже если есть. Даже если в собственности.
DOO>Даже если на своей земле.

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

SK>>>>в трех экземплярах в разных географических регионах,
DOO>>>Значит тоже нужны каналы связи. Если это разные регионы, то сильно сомневаюсь, что канал свой. А если свой, то там такие кап. затраты и операционные затраты, что дальше можно не считать.
SK>>А до "облака" канал связи стало быть уже и не нужен?
DOO>не передергивай. В своем расчете ты их исключаешь, а в облаке требуешь учесть.

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

DOO>>>Опять-таки, организаций которым нужна регионально-распределенная катастрофоустойчивость тоже крайне мало.
SK>>Ну, не скажи, не скажи...
DOO>Скажу. Реально от ИТ так сильно зависят только телеком и банки. Банки чаще всего обходятся локальной катастрофоучтойчивостью.

медицина. наука. финансы. производство. и пожалуй все что крупнее 100 миллионов в год. я сразу сказал "НЕ тяп-ляп стартап".

и кстати да. катастроф-устойчивые удаленные локации — это не обязательно еще один офис с комплектом оборудования. это может быть сейф в банке, куда ленточки завозятся курьером.

SK>>У меня за все время "полетело" две ленточки. В расчетах сделан запас на это. Периодически проверять нужно любой архив. Привод обслуживать конечно надо. но это копеечные затраты. входящие в стоимость носителя.
DOO>Да неверно это. Тебе как минимум надо нанять человека, который будет заниматься заменой и учетом ленточек. При таком количестве ленточек (и отсутствии библиотеки-робота) это уже не копеечные затраты.

Ну, если хранить ленточки в куче в углу то да. А если на полочках в стеллаже то это ноль производственных затрат. библиотека рассматривалась, но была признана не целесообразной тратой при обычном сценарии использовании — замене двух-четырех ленточек в день.

SK>>Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.
DOO>Да ладно... вот гугл меня сидит и обманывает...

Он не обманывает. он про это не говорит. ты сам себе придумал и веришь.

DOO>>>И сколько ты платишь тому, кто ручками постоянно меняет ленточки в приводах? Это ж не роботы у тебя по 2000 баксов-то...
SK>>младший админ раз в день уделяет 10 минут на замену ленточки. раз в неделю он бросает монетку и проверяет случайную ленту из предыдущих бэкапов на читаемость в принципе, на целостность архива и возможность восстановить. Это полуавтоматический процесс. Ручного там только сменить ленту и нажать несколько кнопок в консоли. Не так уж и трудно оторваться от контры на пол часа.
DOO>Сколько он еще успеет накосячить по дороге? И главное — этот человек у тебя все равно есть и несешь на него затраты.

Вот именно. Если я перенесу хранилище в облако этот человек, его косяки и затраты на него у меня все равно останутся.

DOO>>>И сколько ты будешь проводить восстановление в своей мега системе, когда надо ручками разобраться с твоими шестью сотнями ленточек?
SK>>На каждой ленточке всё подписано. "день 240" "Неделя 31" "Год 2014 часть 2" Что там разбираться?
DOO>И их 600 одной стопкой стоит?

По порядку, рядком на полочках.

SK>>>>$10 000 на 5 лет.
SK>>>>$2000 в год.
SK>>>>$166 в месяц за хранение 1800 ТБ. почти два петабайта.
DOO>>>Красиво, но посчитано некорректно.
SK>>Не вопрос. Покажи свои расчеты.
DOO>+ затраты на помещение. Можно даже пропорционально месту, которое занимают ленточки и приводы.

оно есть. и в том и в другом случае.

DOO>+ затраты на админа (или кого угодно), кто обслуживает систему

оно есть. и в том и в другом случае.

DOO>+ ЗИП, затраты на ремонт и пр.

ЗИП — ленточки куплены с запасом. два привода для резервирования. пятилетний гарантийный ремонт входит в стоимость контракта на покупку. раз в год приезжает специальный человек для профилактики, протирает пыль, смазывает узлы и еще что то делает.

DOO>+ риски потери данных (надо отдельно оценивать)

оно есть. и в том и в другом случае.

DOO>+ затраты на апгрейд как-то надо размазать (частично можно в текущий ремонт запихать, но все же)

оно есть. и в том и в другом случае.

DOO>+ электричество на работу приводов, затраты на кондиционирование (благо на привод копейки, но все же) и прочий микроклимат серверного помещения

оно есть. и в том и в другом случае.

DOO>и т.п. (это я только сходу вспомнил — если посмотреть труды тех же APC или VMware, то у них еще можно статей расхода натягать).

Это не расчеты. Это туманный ответ на вопрос "почему я не хочу так делать".

Ты хотя бы на салфетке эскиз расчетов набросай, как это сделал я.

DOO>>>А так, цена примерно на уровне 0.5 цента за 1 Gb в месяц. Если считать по-честному (см. выше), то получится выгоднее местами.
SK>>у меня как раз все понятно. мне они не нужны. реплика между площадками делается всегда автоматически. при канале 10 мегабит в пике занимает полосу до 2. все остальное на нужды офиса.
DOO>Ииии? В чем проблема если примерно то же будет организовано у меня с облаком?

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

Ты в своих "расчетах" забыл политику.

DOO>К слову, у амазона есть еще интересный сервис — Glacier. Там 3 Tb уже тупо дешевле ленточки стоят (ну, если смотреть ее реальную стоимость, а не 10 баксов, взятые непонятно откуда). Учитывая, как у тебя устроен архив, сравнивать с таким сервисом корректнее, так как обычный облачный сторедж — это почти онлайн доступ.
DOO>Единственный минус — тут реально одна площадка.

О том и речь.

Да. Облако тебе какой SLA предлагает? Сколько суток они будут тикет рассматривать?

Все проблемы от жадности и глупости

C>А что, надо отвечать на очевидные вопросы?

Ну если бы они были очевидны, ты бы на него ответил сразу

C>В случае со своим железом, я точно так же подниму новые инстансы на Амазоне — если вдруг понадобится.

У тебя весь софт на твоем железе все настроено так, чтобы раз — и подняться без проблем на Амазоне? У тебя софт и Амазон настроены так, чтобы бесшовно проинтегрировать софт на твоем железе с поднятыми на Амазоне инстансами?

Что-то мне подсказывает, что это далеко не так.

Здравствуйте, DOOM, Вы писали:

SK>>Это не расчеты. Это туманный ответ на вопрос "почему я не хочу так делать".
SK>>Ты хотя бы на салфетке эскиз расчетов набросай, как это сделал я.
DOO>Честно — лень.

я так и думал.

Все проблемы от жадности и глупости

Здравствуйте, DOOM, Вы писали:

DOO>К слову, у амазона есть еще интересный сервис — Glacier. Там 3 Tb уже тупо дешевле ленточки стоят (ну, если смотреть ее реальную стоимость, а не 10 баксов, взятые непонятно откуда).

Ну если допустить, что ты эти данные никогда не будешь оттуда читать, то может быть и дешевле. Но /dev/null в этом случае вообще совершенно бесплатен.

Здравствуйте, DOOM, Вы писали:

DOO>Пол петабайта, к слову, интересное число, потому что есть фиксированные тарифные планы на 500 Tb — порядка 30 баксов в месяц (!)

Это где такие волшебные тарифы?

Здравствуйте, consign, Вы писали:

C>Здравствуйте, DOOM, Вы писали:

DOO>>К слову, у амазона есть еще интересный сервис — Glacier. Там 3 Tb уже тупо дешевле ленточки стоят (ну, если смотреть ее реальную стоимость, а не 10 баксов, взятые непонятно откуда).
C>Ну если допустить, что ты эти данные никогда не будешь оттуда читать, то может быть и дешевле. Но /dev/null в этом случае вообще совершенно бесплатен.
Тебе для архивных данных 1000 запросов в месяц мало????

Здравствуйте, DOOM, Вы писали:

DOO>Тебе для архивных данных 1000 запросов в месяц мало????

Ты вообще считал, во сколько тебе обойдется извлечение данных оттуда?

Здравствуйте, smeeld, Вы писали:

S>Sun уже действовала на пути удешевления того, что сейчас величают cloud-ами, и представленного
S>до Sun-ов в виде IBM-овских майнфреймов. Первыми cloud-ами были те самые майнфреймы, более того,
S>тогда это было единственной формой организации вычислений.

Всё развивается по спирали, персональные устройства снова превращаются в терминалы.

Здравствуйте, Mamut, Вы писали:

M>Что-то мне подсказывает, что это далеко не так.

Говори за себя.

M>>Что-то мне подсказывает, что это далеко не так.
C>Говори за себя.

То есть у тебя есть все то, что я описал, да?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Не были они облаками. Неотъемлемый признак облака — динамеческое распределение ресурсов большой кластерной сети. А мейнфрейм — он мейнфрейм и есть.

Вы точно знаете что такое майнфрейм, и читали спеки по его эксплуатации, обслуживанию? Ресурсы любого майнфрейма прежде
всего разбиваются на части, которые по отдельности используются. Так что майнфремы не только первые облака, но и первая
виртуализация.

Здравствуйте, smeeld, Вы писали:

НС>>Точно знаю. А ты точно знаешь что такое облако? В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.
S>Тоже самое в майнфрейме, или забыли как в те времена торговали количеством процессорных ресурсов, памяти?

Не то же самое. Сколько железа у тебя в мейнфрейме есть, столько и есть, и больше не будет, как ты не виртуализуй.

S>Это несколько иначе, чем в современных облаках, но это только в деталях, в принципе всё то же самое.

Ну, с таким принципом и ноутбук облако — тоже можно виртуализовать и квотировать.

S>Не только сменой, ресурсы можно наращивать, причём "в горячую", что есть большой OK для для задач финансовой
S>сферы.

Наращивать все равно можно только физически.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.

А уместить эти ресурсы в рамки одного инстанса этого самого облака?

Здравствуйте, smeeld, Вы писали:

НС>>Не то же самое. Сколько железа у тебя в мейнфрейме есть, столько и есть, и больше не будет, как ты не виртуализуй.
S>В кластерах тоже наращивание ограничено в некотором смысле.

В тех кластерах, которые стоят за облаками — в практическом смысле не ограничено. И, в любом случае, это не твоя проблема.

Здравствуйте, Anton Batenev, Вы писали:

НС>> В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.
AB>А уместить эти ресурсы в рамки одного инстанса этого самого облака?

А на Луну слетать? К чему этот вопрос?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> НС>> В облаке ты можешь заказать столько аппаратных ресурсов, сколько тебе нужно.
НС> AB>А уместить эти ресурсы в рамки одного инстанса этого самого облака?
НС> А на Луну слетать? К чему этот вопрос?

К тому, что ты не можешь заказать столько ресурсов, сколько тебе нужно — облачная нода, как и мэйнфрейм, точно так же ограничена железом.

Здравствуйте, consign, Вы писали:

C>Если ты гоняешь железо 24 часа в сутки и не учитываешь ремонт и обслуживание, оно окупается вообще за 3 месяца, по сравнению с EC2.
Наши специалисты к вам вылетели. Оставайтесь на своём месте, и не делайте резких движений.

Зарезервированные узлы на Амазоне стоят примерно столько же, сколько и своё железо.

Спотовые узлы стоят дешевле своего железа, они практически по цене электричества. Например, Дисней нынче использует их для рендеринга своих фильмов ("Finding Dory" вот прямо сейчас рендерится).

Если же учесть необходимость резервирования, аппаратной балансировки нагрузки, избыточной сетевой связности, физической безопасности серверов и т.п., то своё железо сливается по полной.

Конечно, если нужна файлопомойка на 10 машин для запуска 1С — тогда всё ещё выгодно купить "сервер" в виде подержанного десктопа и поставить его в углу.

Здравствуйте, Stanislaw K, Вы писали:

SK>У меня за все время "полетело" две ленточки. В расчетах сделан запас на это. Периодически проверять нужно любой архив. Привод обслуживать конечно надо. но это копеечные затраты. входящие в стоимость носителя.
А храним ленты где? В сейфе рядом? А если пожар/наводнение/рейд ОМОНа?

SK>>>и так. для борьбы на равных с облаком возьмем одну локацию.
DOO>>Облако почти всегда много локаций — так что это будет не на равных как раз.
SK>Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.
Сервисы Amazon бесплатны в пределах одного региона — это политика такая. Так что если используется S3 или Glacier для хранения данных, то неважно из какой зоны доступности внутри региона к ним обращаться.

"Зоны доступности" — это полностью физически отдельные дата-центры с раздельными системами кондиционирования и электропитания, хотя и расположенные в географической близости.

Здравствуйте, consign, Вы писали:

C>Ну если допустить, что ты эти данные никогда не будешь оттуда читать, то может быть и дешевле. Но /dev/null в этом случае вообще совершенно бесплатен.
В Glacier платится за пиковый bandwidth. Сколько у вас там, 10Мбит канал до офиса?

Тогда в месяц Glacier будет стоить не более $1000 в месяц на извлечение данных. Это если бесплатных 5% в месяц недостаточно будет и захочется весь канал забить на трафик восстановления на весь месяц.

Здравствуйте, Cyberax, Вы писали:

SK>>У меня за все время "полетело" две ленточки. В расчетах сделан запас на это. Периодически проверять нужно любой архив. Привод обслуживать конечно надо. но это копеечные затраты. входящие в стоимость носителя.
C>А храним ленты где? В сейфе рядом? А если пожар/наводнение/рейд ОМОНа?

курьер забирает ленточку и увозит в подземный бункер за 900 км.
ему на встрече едет курьер с лентой для следующего бэкапа.
NDA
рядом стоит полка NAS с оперативными бэкапами 5 15 и 60 минут.


SK>>Это маркетинговый bullshit. Стоимость облака с множеством локаций кратно увеличивается.
C>Сервисы Amazon бесплатны в пределах одного региона — это политика такая. Так что если используется S3 или Glacier для хранения данных, то неважно из какой зоны доступности внутри региона к ним обращаться.

я не уловил, это ты к чему? мне, головной офис в СПб РФ, для катастрофоустойчивости желательно хранить данные на других континетнах, учитывает ли амазон что я вхожу в единый галактический регион, солнечную систему, или оно скажет что я не отношусь ни к европе ни к азии?.

C>"Зоны доступности" — это полностью физически отдельные дата-центры с раздельными системами кондиционирования и электропитания, хотя и расположенные в географической близости.

близости от чего?

Все проблемы от жадности и глупости

Здравствуйте, Cyberax, Вы писали:

C>Например, я могу парой кликов запустить кластер из 5 тысяч процессоров по цене около $100 в час. Сколько там стоит mainframe с такой вместительностью?

Надоело повторять тут, что не все задачи параллелятся, более того, задачи "на миллион", например,
связанные с обработкой финтранзакций, на крастере точно не запустите, или оно томрозить будет адово.
В таких задачах 128 CPU в одном юните оказываются гораздо более востребованы, чем 100000 CPU, разбросанные
по тысячам нод кластера. Майнфреймы с коболом и явой до сих пор живы и здоровы, они кое кому нужны, и за них
готовы платить те деньги, что они стоят.

Здравствуйте, Stanislaw K, Вы писали:

C>>А храним ленты где? В сейфе рядом? А если пожар/наводнение/рейд ОМОНа?
SK>курьер забирает ленточку и увозит в подземный бункер за 900 км.
А точно не в соседний подвал?

C>>Сервисы Amazon бесплатны в пределах одного региона — это политика такая. Так что если используется S3 или Glacier для хранения данных, то неважно из какой зоны доступности внутри региона к ним обращаться.
SK>я не уловил, это ты к чему? мне, головной офис в СПб РФ, для катастрофоустойчивости желательно хранить данные на других континетнах, учитывает ли амазон что я вхожу в единый галактический регион, солнечную систему, или оно скажет что я не отношусь ни к европе ни к азии?.
S3 поддерживает кросс-региональную репликацию, так что не проблема. Вопрос с экспортом в другую Галактическую Группу сейчас решается.

C>>"Зоны доступности" — это полностью физически отдельные дата-центры с раздельными системами кондиционирования и электропитания, хотя и расположенные в географической близости.
SK>близости от чего?
Друг от друга. Т.е. для репликации между зонами можно считать, что сетевая задержка пренебрежимо мала. Между регионами это уже не работает.

Здравствуйте, smeeld, Вы писали:

C>>Например, я могу парой кликов запустить кластер из 5 тысяч процессоров по цене около $100 в час. Сколько там стоит mainframe с такой вместительностью?
S>Надоело повторять тут, что не все задачи параллелятся, более того, задачи "на миллион", например,
S>связанные с обработкой финтранзакций, на крастере точно не запустите, или оно томрозить будет адово.
<крупный_инвестиционный_банк>, который на нашем облаке считает деривативы, смотрит на тебя с недоумением.

S>В таких задачах 128 CPU в одном юните оказываются гораздо более востребованы, чем 100000 CPU, разбросанные
S>по тысячам нод кластера.
У нас уже анонсирован тип узлов с 128 CPU и 512GB RAM. Прямо сейчас доступны узлы с 40 CPU и 256G RAM — вставляй кредитную карту и пользуйся.

Хочется быстрый кластер? Не проблема, используй placement groups — они будут гарантировать, что узлы находятся физически не далее одного интерконнекта. 20ГБ пропускной способности на хост будут гарантированы.

У Microsoft есть даже InfiniBand с RDMA, что уже настоящий суперкомпьютерный уровень.

S>Майнфреймы с коболом и явой до сих пор живы и здоровы, они кое кому нужны, и за них
S>готовы платить те деньги, что они стоят.
Да никому они не нужны. Эти копролиты работают только из-за того, что говнокод с них портировать дороже, чем делать ему искусственное дыхание.

В общем, если ты покупаешь продукты от IBM или SunOracle — ты лох. Это уже было верно в течение последних примерно 10 лет.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, Cyberax, Вы писали:

C>>Например, я могу парой кликов запустить кластер из 5 тысяч процессоров по цене около $100 в час. Сколько там стоит mainframe с такой вместительностью?

S>Надоело повторять тут, что не все задачи параллелятся, более того, задачи "на миллион", например,
S>связанные с обработкой финтранзакций, на крастере точно не запустите, или оно томрозить будет адово.
S>В таких задачах 128 CPU в одном юните оказываются гораздо более востребованы, чем 100000 CPU, разбросанные
S>по тысячам нод кластера. Майнфреймы с коболом и явой до сих пор живы и здоровы, они кое кому нужны, и за них
S>готовы платить те деньги, что они стоят.

- Крхгррррр, — сказала пила
— Уууууу, б... — сказали мужики

Что за привычка попытаться выдумать искусственный нежизненный пример и потом начать им размахивать со словами "говно ваши облака — вот это не могут".
Особенно смешно выглядит, когда тебе в соседнем же сообщении показывают, что не все так плохо, как ты себе представляешь.

К слову, линейка серверов HPC у всех производителей загибается. MS давно забил на винду под итаниум. Знаешь почему? потому что это все стало ну настолько нишевым, что серийное производство подобного оборудования и ПО уже попросту нерентабельно.
Но надо, блин, вспоминать мхом поросшие мэйнфреймы с периодом окупаемости десятки лет, при том, что модель 3-4-х летней давности в полном фарше проигрывает по всем показателям парочке "обычных" современных x86-х серверов, которые хоть каждый год обновляй (но еще лучше не париться и взять облачный сервис).

Здравствуйте, Cyberax, Вы писали:

C><крупный_инвестиционный_банк>, который на нашем облаке считает деривативы, смотрит на тебя с недоумением.

Когда он запустит АБС, ERP и RDBMS на несколько сотен террабайт критичных данных под крейсерской нагрузкой у вас
на куче тазиков, тогда и поговорим.

C>Хочется быстрый кластер? Не проблема, используй placement groups — они будут гарантировать, что узлы находятся физически не далее одного интерконнекта. 20ГБ пропускной способности на хост будут гарантированы.

Сколько можно, попытки заменить SMP связкой тазиков разного варианта, от "по ethernet" до "по RDMA",
уже двадцать лет идут, но что-то SGI, впервые такое клепавшая из этой категории, обанкротилась давным давно, а IBM и oracle
продолжают клепать всё новые и новые SMP монстры, это они так играются и работают себе в убыток?

C>Да никому они не нужны. Эти копролиты работают только из-за того, что говнокод с них портировать дороже, чем делать ему искусственное дыхание.
C>В общем, если ты покупаешь продукты от IBM или SunOracle — ты лох. Это уже было верно в течение последних примерно 10 лет.

Смотрите сообщение про АБС, ERP, RDBMS выше, если Вы будете говорить о возможности их полноценного
исполнения на кластере тазиков, то Вы просто не имеете представления о чём идёт речь.

Здравствуйте, Cyberax, Вы писали:


C>>>"Зоны доступности" — это полностью физически отдельные дата-центры с раздельными системами кондиционирования и электропитания, хотя и расположенные в географической близости.
SK>>близости от чего?
C>Друг от друга. Т.е. для репликации между зонами можно считать, что сетевая задержка пренебрежимо мала. Между регионами это уже не работает.

Вернемся к моменту когда ЧП произошло: сколько времени будет восстанавливаться бэкап из облака, на твою локальную информационную систему?

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

C>>Друг от друга. Т.е. для репликации между зонами можно считать, что сетевая задержка пренебрежимо мала. Между регионами это уже не работает.
SK>Вернемся к моменту когда ЧП произошло: сколько времени будет восстанавливаться бэкап из облака, на твою локальную информационную систему?
"Локальную информационную систему"? Это что-то из 19-го века?

Если речь идёт о серьёзном применении — покупаем выделенные каналы на нужную вместимость и устанавливаем прямой пиринг с датацентром Амазона: https://aws.amazon.com/directconnect/

Здравствуйте, smeeld, Вы писали:

C>><крупный_инвестиционный_банк>, который на нашем облаке считает деривативы, смотрит на тебя с недоумением.
S>Когда он запустит АБС, ERP и RDBMS на несколько сотен террабайт критичных данных под крейсерской нагрузкой у вас
S>на куче тазиков, тогда и поговорим.
Всё есть. И хранилища данных на сотни терабайт (RedShift), и ERP (самая популярная ERP в мире, кстати, облачная).

АБС — это антиблокировочная система для тормозов? Её нет, так как не тормозим.

C>>Хочется быстрый кластер? Не проблема, используй placement groups — они будут гарантировать, что узлы находятся физически не далее одного интерконнекта. 20ГБ пропускной способности на хост будут гарантированы.
S>Сколько можно, попытки заменить SMP связкой тазиков разного варианта, от "по ethernet" до "по RDMA",
Узел с 128 CPU (каждый из которых ещё и двухядерный) — это примерно максимум того, что нужно. Дальше просто смысла нет.

S>уже двадцать лет идут, но что-то SGI, впервые такое клепавшая из этой категории, обанкротилась давным давно, а IBM и oracle
S>продолжают клепать всё новые и новые SMP монстры, это они так играются и работают себе в убыток?
Да, примерно так. Sun продалась ради Java, а IBM только лохам железо и впаривает (всё меньше с каждым годом).

SGI, кстати, клепала как раз большие SMP с помощью Cray. К успеху уверенно шла, но не фартануло.

C>>В общем, если ты покупаешь продукты от IBM или SunOracle — ты лох. Это уже было верно в течение последних примерно 10 лет.
S>Смотрите сообщение про АБС, ERP, RDBMS выше, если Вы будете говорить о возможности их полноценного
S>исполнения на кластере тазиков, то Вы просто не имеете представления о чём идёт речь.
Причём тут АБС и прочие системы курсовой устойчивости?

Они не имеют никакого отношения к mainframe'ам. Собственно, если посмотреть на Oracle, то они двигают RAC, который представляет из кластерную систему с общим хранилищем.

Естественно, ни одна из компаний не делает "воооооооот тааааакие SMP с 100500 процессорами" — это никому нафиг не нужно.

Кстати, вот новость прошла — даже ЦЕРН будет данные считать на нашем облаке. Но видимо, у них там несерьёзные рассчёты, не дотягивают до уровня программ на КОБОЛе.

Здравствуйте, Cyberax, Вы писали:

C>>>Друг от друга. Т.е. для репликации между зонами можно считать, что сетевая задержка пренебрежимо мала. Между регионами это уже не работает.
SK>>Вернемся к моменту когда ЧП произошло: сколько времени будет восстанавливаться бэкап из облака, на твою локальную информационную систему?
C>"Локальную информационную систему"? Это что-то из 19-го века?

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

C>Если речь идёт о серьёзном применении — покупаем выделенные каналы на нужную вместимость и устанавливаем прямой пиринг с датацентром Амазона: https://aws.amazon.com/directconnect/

Накидай расчеты, примерный порядок, во сколько это обойдется за 5 лет эксплуатации.

Все проблемы от жадности и глупости

Здравствуйте, smeeld, Вы писали:

S>Вы вот так говорите, потому-что ничего сложнее задач постинга котиков в инете и PC-шных
S>свистелок-перделок для юзера в глаза не видели, но мнение имеете.
Конечно. А неудобные фразы о том, что производители забили на этот сегмент рынка надо не приводить, чтобы свое мнение звучало авторитетнее

Здравствуйте, smeeld, Вы писали:

S>Когда он запустит АБС, ERP и RDBMS

SAP уже давно никто не использует на супердомах или старших сановских серверах. Там их давно и надолго выбили блейдовые x86 решения типа HP или Cisco UCS.
Microsoft выпускает свой SQL сервер только на платформу x86 — итаниум не взлетел.
Oracle давно забил на большие железки для своей СУБД и пропихивает базовые модели Sun'а как аппаратную платформу.

Все эти решения прекрасно параллелятся и масштабируются и не нужны большие системы для них.

А да, АБС совкового производства до сих пор по привычке работают на IBM'овских P'шках, купленных лет 10 назад. Ниче, что это P'шка по вычислительной мощи может уже проигрывать моему домашнему компу? А эксплуатировать ее еще лет 20 надо, иначе не окупится.
Ну и ваши любимые мейнфремы — это 32 или 64 процессора. По сути, одноядерных.
В махонький блейдовый сервер можно запихать 4 12-ти ядерных процессора и террабайт оперативной памяти. Еще вопросы?

Здравствуйте, Cyberax, Вы писали:

C>IBM только лохам железо и впаривает (всё меньше с каждым годом).

Если что, IBM сливает железячный бизнес в lenovo. Не было у них консультанта в лице smeeld

Здравствуйте, Cyberax, Вы писали:

C>SGI, кстати, клепала как раз большие SMP с помощью Cray. К успеху уверенно шла, но не фартануло.

Там были не SMP, там были NUMA кластеры.

C>Они не имеют никакого отношения к mainframe'ам. Собственно, если посмотреть на Oracle, то они двигают RAC, который представляет из кластерную систему с общим хранилищем.

RAC они двигали, когда у них не было технологичекого портфеля SPARC+Solaris и лепили из говна и палок
кучи тазиков с x86+linux. Особо не взлетел ни RAC, ни Exadata, а вот новые шкафы с SPARC MX раскупаются как горячие
пирожки банками и телекомами, инфа от чуваков из Канады, занимающихся деплойментом этих решений.

C>Кстати, вот новость прошла — даже ЦЕРН будет данные считать на нашем облаке. Но видимо, у них там несерьёзные рассчёты, не дотягивают до уровня программ на КОБОЛе.

Повторю ещё раз, кластер-это кластер, SMP-это SMP, и для каждой машины свои задачи. И если Вы не знаете
каке задачи никогда не смогут полноценно работать на кластерах, то Вы или троллите, или просто
не в курсе многих вещей, но мнение имеете.

Здравствуйте, Stanislaw K, Вы писали:

C>>"Локальную информационную систему"? Это что-то из 19-го века?
SK>Это общепринятый термин обозначающий, в данном контексте, сервера и рабочие станции стоящие здесь у меня локально, в офисе.
Ну так и думал — из прошлого тысячелетия.

C>>Если речь идёт о серьёзном применении — покупаем выделенные каналы на нужную вместимость и устанавливаем прямой пиринг с датацентром Амазона: https://aws.amazon.com/directconnect/
SK>Накидай расчеты, примерный порядок, во сколько это обойдется за 5 лет эксплуатации.

- Петька, приборы!
— 120!
— Что 120?
— А что "приборы"?

Не зная требований, ситуации и возможностей — невозможно сказать сколько будет стоить какое-либо решение.

Здравствуйте, smeeld, Вы писали:

C>>SGI, кстати, клепала как раз большие SMP с помощью Cray. К успеху уверенно шла, но не фартануло.
S>Там были не SMP, там были NUMA кластеры.
NUMA — это подмножество SMP. Не выдумывай свою терминологию.

C>>Они не имеют никакого отношения к mainframe'ам. Собственно, если посмотреть на Oracle, то они двигают RAC, который представляет из кластерную систему с общим хранилищем.
S>RAC они двигали, когда у них не было технологичекого портфеля SPARC+Solaris и лепили из говна и палок
S>кучи тазиков с x86+linux.
И что же магического этот "портфель" сделал? Ах да, принёс убытки.

Oracle hardware revenue:
2011 — $4B
2014 — $3B
2015 — $2.9B

Це велика перемога!

S>Особо не взлетел ни RAC, ни Exadata, а вот новые шкафы с SPARC MX раскупаются как горячие
S>пирожки банками и телекомами, инфа от чуваков из Канады, занимающихся деплойментом этих решений.
Лохов ещё много. Но не так много — у Оракла который год доход от железа плоский.

Потому они применяют для продаж метод: "А не будут брать, отключим газпроведём аудит!" ( http://fortune.com/2015/09/14/oracle-plays-hardball/ ).

C>>Кстати, вот новость прошла — даже ЦЕРН будет данные считать на нашем облаке. Но видимо, у них там несерьёзные рассчёты, не дотягивают до уровня программ на КОБОЛе.
S>Повторю ещё раз, кластер-это кластер, SMP-это SMP, и для каждой машины свои задачи.
Ну так какие же задачи нужны для мега-SMP, который делает IBM, но не показывает? Запуск программ на КОБОЛе, написанных в 1964-м году?

S>И если Вы не знаете
S>каке задачи никогда не смогут полноценно работать на кластерах, то Вы или троллите, или просто
S>не в курсе многих вещей, но мнение имеете.
Я вот вижу, что на нашем облаке успешно запускают примерно всё — от серверов для показа котиков до квантовых вычислений. Но ведь это невозможно, так как оно "не SMP"!