s3 outage details posted

[zVlad]

Kolbassov, пока я по делам отъеду поясните, пожалуйста, алгоритм рентования серверов в облаке Амазона и их освобождения. Делается ли это автоматом и на основании каких показателей, как эти показатели измеряются.

Для начального ознакомления почитайте здесь: https://aws.amazon.com/autoscaling/ Кстати, студентам это было бы намного интереснее и полезнее чем обзор компьютеров типа Z. Сейчас тенденция "lease not own" во многих отраслях.

Про эту хрень им и без меня много мозги компостируют. Я буду рассказывать о том что они не узнают иначе.

[uncle_Pasha]

Мы не знаем сколько дисков у Амазон s3. И сколько серверов эти диски качает.

Почему не знаем? Они периодически сообщают свои цифры. Правда, они обычно оперируют количеством объектов (например, файлов - максимальный размер 5TB). Речь идет о десятках-сотнях ексабайтов, т.е. на 3-5 порядков выше теоретической максимальной емкости МФ.
При стоимости ГБ меньшей на несколько порядков.

[Kolbasoff]

Прочитал. И это все?

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

[zVlad]

Как я и предполагал ничего кроме CPU utulization и predictable load changes с вытекающим из этого scheduling ничего предложено быть и не могло.
Элементарное зацикливание приведет к подбрасыванию дровишек в костер.
Настоящий workload managment может быть только тогда когда есть возможность измерять пользовательские показатели такие как responsе time и пропускная способность. Измерять и сравнивать с задаными значениями.
Такими возможностями обладает только Work Load Manager (WLM) в zOS. Кроме того только на МФ есть реальная Capacity on Demand (CoD) возможность, которая в состоянии оценивать потребности загрузки и маневрировать ресурсами.
Вот об этом, в числе прочего, я буду рассказывать студентам. Чтобы они знали реальные горизонты в ИТ, а не два притопа три прихлопа предоставляемые AutoScaling.

[zVlad]

Мы не знаем сколько дисков у Амазон s3. И сколько серверов эти диски качает.

Почему не знаем? Они периодически сообщают свои цифры. Правда, они обычно оперируют количеством объектов (например, файлов - максимальный размер 5TB). Речь идет о десятках-сотнях ексабайтов, т.е. на 3-5 порядков выше теоретической максимальной емкости МФ.
При стоимости ГБ меньшей на несколько порядков.

Максимальный размер одного набора данных в zOS - 128 ТБ. 3-5 порядков это Вы из моих оценок пределов для нашего (один сервер), entry level, МФ почерпнули? Или Вы самостоятельно разыскали числа для, скажем так, Parallel SysPlex и сравнили их с тем что есть у Амазона? Тогда покажите Ваши источники и дайте Ваши расчеты.
Вы забыли, или не можете, показать общее количество серверов, которые ворочают те "десятки-сотни ексабайтов" в Амазоне. А я давал числа по одному инстансу системы на самом маленьком МФ. Один z13 сервер може тянуть 85 таких инстансев.

[uncle_Pasha]

Как я и предполагал ничего кроме CPU utulization и predictable load changes с вытекающим из этого scheduling ничего предложено быть и не могло.

Вы бы почитали http://docs.aws.amazon.com/autoscaling/ ... _plan.html
В большинстве случаев все скейлится на базе метрик, которые в принципе могут быть любыми (utilization/latency/response time/etc).
CPU utilization - это лишь один из примеров.

[uncle_Pasha]

Максимальный размер одного набора данных в zOS - 128 ТБ. 3-5 порядков это Вы из моих оценок пределов для нашего (один сервер), entry level, МФ почерпнули? Или Вы самостоятельно разыскали числа для, скажем так, Parallel SysPlex и сравнили их с тем что есть у Амазона? Тогда покажите Ваши источники и дайте Ваши расчеты.

Вы же у нас специалист в МФ, так покажите конфигурацию, которая будет емкость в сотню ексабайт, и хорошо бы прикинуть стоимость.

[zVlad]

Прочитал. И это все?

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

Да нечего там рассказывать. Кроме реакции на высокое/низкое использование CPU (высокое/низкое это сколько?) и гадание на кофейной гуще (предсказание-prediction) в этих Ваших облаках больше не на что опереться, там больше нет ничего за что можно было бы зацепиться и подбрасывать дровишек, или их уменьшать, чтобы обеспечить 1 секунду response time, например.

[Kolbasoff]

Кроме того только на МФ есть реальная Capacity on Demand (CoD) возможность, которая в состоянии оценивать потребности загрузки и маневрировать ресурсами.

Ресурсы у МФ фиксированные, они уже есть и за них уже заплачено. В облаке ресурсы рентуются у провайдера когда необходимо и отдаются обратно когда не надо. Оплата почасовая. Идея такая же как у zipcar, например.

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

Удачи. Приготовтесь отвечать на неудобные вопросы типа "нафига мне это надо если на всю страну 10 мэйнфреймов".

[zVlad]

Максимальный размер одного набора данных в zOS - 128 ТБ. 3-5 порядков это Вы из моих оценок пределов для нашего (один сервер), entry level, МФ почерпнули? Или Вы самостоятельно разыскали числа для, скажем так, Parallel SysPlex и сравнили их с тем что есть у Амазона? Тогда покажите Ваши источники и дайте Ваши расчеты.

Вы же у нас специалист в МФ, так покажите конфигурацию, которая будет емкость в сотню ексабайт, и хорошо бы прикинуть стоимость.

Ну да, конечно, стоимость. Вы необычайно долго продержались прежде чем метнулись в это любимое укрытие.
Я показал потенциальные 60 000 ТБ на малюсеньком МФ с одной zOS. Теперь Ваша очередь показывать сотни ексабайт и их цену. Потом буду отвечать я. Жду.

[zVlad]

Кроме того только на МФ есть реальная Capacity on Demand (CoD) возможность, которая в состоянии оценивать потребности загрузки и маневрировать ресурсами.

Ресурсы у МФ фиксированные, они уже есть и за них уже заплачено. В облаке ресурсы рентуются у провайдера когда необходимо и отдаются обратно когда не надо. Оплата почасовая. Идея такая же как у zipcar, например.

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

Удачи. Приготовтесь отвечать на неудобные вопросы типа "нафига мне это надо если на всю страну 10 мэйнфреймов".

Рентовка всегда дороже будет владения. Рентовкой Вы кроме того что сами бы заплатили платите прибыл рентодателю. Для коротких потребностей рентовка выгоднее. Вот я еду на четыре дня в Крым. Вообще то я собираюсь ходить пешком, но решая задачу перезда из аэропорта в Ялту и обратно я понял что мне проще, и дешевле, будет взять машину в рент на четыре дня. Пусть она будет стоять и ждать когда я вернусь с маршрута, но переезд из аэропорта в Ялту (3000 рублей на такси) и обратно окупят 4 дня рентовки и мне не надо будет зависить от расписания автобусов. Но в настоящем ИТ такие ситуации когда нужно заткнуть быстро маленькую дырочку редки на самом деле,
Что касается "на фига мне это надо" то такие вопросы потому и могут быть что в России никто на дает МФ. Тем не менее, даже в Челябинске, где нпт ни одного МФ, есть фирма ищущая программистов со знанием МФ.
Если у Вас есть еще советы к моим лекция, пожалуйста, поделитесь. Я Вам буду очень благодарен.

[Kolbasoff]

Да нечего там рассказывать. Кроме реакции на высокое/низкое использование CPU (высокое/низкое это сколько?) и гадание на кофейной гуще (предсказание-prediction) в этих Ваших облаках больше не на что опереться, там больше нет ничего за что можно было бы зацепиться и подбрасывать дровишек, или их уменьшать, чтобы обеспечить 1 секунду response time, например.

Вам уже показали, что это не так. Облака вобрали достижения в ИТ из всех областей, в том числе и из МФ. И денег у них амазонщиков больше, так что новое будет появляться именно там, а не в МФ. Но у МФ есть своя ниша - поддерживать корпоративные легаси системы. Их даже никто и не переписывает, они тихо умирают с конторой, когда клиенты уходят к тем конкурентам, где услуги лучше и дешевле. Вот как например появляется Амазон, и нет JCPenny. Или вылез Убер и нет желтых таксишек. Богадельни, особенно гос и монополисты, будут жить долго, но находится там вредно для здоровья, как вы сами это прекрасно знаете.

[zVlad]

Да нечего там рассказывать. Кроме реакции на высокое/низкое использование CPU (высокое/низкое это сколько?) и гадание на кофейной гуще (предсказание-prediction) в этих Ваших облаках больше не на что опереться, там больше нет ничего за что можно было бы зацепиться и подбрасывать дровишек, или их уменьшать, чтобы обеспечить 1 секунду response time, например.

Вам уже показали, что это не так. Облака вобрали достижения в ИТ из всех областей, в том числе и из МФ. И денег у них амазонщиков больше, так что новое будет появляться именно там, а не в МФ. Но у МФ есть своя ниша - поддерживать корпоративные легаси системы. Их даже никто и не переписывает, они тихо умирают с конторой, когда клиенты уходят к тем конкурентам, где услуги лучше и дешевле. Вот как например появляется Амазон, и нет JCPenny. Или вылез Убер и нет желтых таксишек. Богадельни, особенно гос и монополисты, будут жить долго, но находится там вредно для здоровья, как вы сами это прекрасно знаете.

Кроме Ваших заблуждений и неуместной пропаганды Вы сегодня чем нибудь порадовать собираетесь?
Я могу Вам рассказать нечто более конкретное и интересное. Последние дни я занимался имплементацией одного приложения, которое я в конце 2015 имплементировал на Линукс в WebSphere, на МФ в WebSphere for zOS. На том самом малюсеньком МФ, где продакшн и все остальные инстансы ERP приложения нашего клиента выполняются (напомню, с 9:00 до 15:00 загрузка CPU на нем в районе 100%).
Я использовал материал (это Java) предоставленный для Линукса. Достигнув определенного прогресса я обратился к поставщику этого приложения с вопросом что им известно о применении их приложения на zOS. Ответили что планируют это сделать. Возмодно я их опережу, мне немного осталось.
А Вы затасканые лозунги про легаси до сих пор носите по улице.

[Kolbasoff]

Если у Вас есть еще советы к моим лекция, пожалуйста, поделитесь. Я Вам буду очень благодарен.

Вопрос практической востребованности ключевой. Это же не фундаментальное знание, а сугубо прикладное ремесло. Еще один вопрос который может возникнуть у студентов: как я могу по-практиковаться хотя бы на базовом уровне? Толку от бочек и прямоугольников на доске ноль, если нет возможности "потрогать" руками. У большинства студентов есть лаптопы под win или mac os. Есть возможность запустит на них виртуалку с имиджем zOS? Еще: форумы по zOS и места где можно срубить халтурку. Студент тоже хочет кушать.

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

[Kolbasoff]

Достигнув определенного прогресса я обратился к поставщику этого приложения с вопросом что им известно о применении их приложения на zOS. Ответили что планируют это сделать.

Продавец никогда не скажет "это у вас работать не будет". Он всегда скажет "мы не покладая рук работаем над тем, что бы сделать вас максимально счастливыми". Иначе это не продавец.