s3 outage details posted

[StrangerR]

Human parameter entry error...
https://aws.amazon.com/message/41926/" onclick="window.open(this.href);return false;

Забавно. Один долбодятел забыл выдать tune2fs -i 0 -c 0 <Big File system>, другой не перевызывал ничего в течении 5 лет (что запросто бывает, у меня такое есть в зоопарке), третий написал софт так что удаление нескольких серверов из зоопарка вызвало полный перевызов, а четвертый зачем то стал играться с клетками во время наплыва посетителей...

Но кстати да. Полного перевызова систем с НУЛЯ амазон, скорее всего, не вынесет уже. Как и много прочих облаков.

[StrangerR]

А валидация бы не позволила забить hostname системы, которая не просто бокс неплательшика, а отвечает за core S3 functionality

Прочитайте внимательно.
"executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process"

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

там вообще не в том дело. Судя по всему, просто система так была написанна, что отключение чуть больше чем ожидалось - приводило к перевызову серверов. Которые, как легко понять, уже лет 5 никто не перевызывал. Которые, как тоже легко понять, скорее всего сказали на перевызове _а мы уже 5 лет не проверяли эти файловые системы, а дайте как мы их проверим_. Или что-то в том-же роде.

Я в такое влетал, благо на бэкап серверах - перевызываешь его и вдруг влетаешь на 5 часовую проверку. Даже если ее выключить, то просто старт с выполнением лога изменений может занять полчаса. И ничем ты это не победишь раз уже однажды влетел. Систему надо строить так, чтобы отвалился кусочек а не вся она... или с кластером (но кластер сам себе буратино, если сломается то еще надольше) или совсем децентраллизованно. У них и human error то не было, так что никакое тестирование и автоматизация тут бы ничем не помогли.

(Правильное решение - все регулярно перевызывать, в низкую нагрузку и по 1 элементу, и контролировать время и статус. У меня в облаке например после апгрейда вдруг перевызов стал занимать вместо 10 минут - 30, а апгрейд занял каких то несчастных 3 часа вместо ожидаемых 30 минут... и это небольшое сравнительно облако. ЧТо будет в большом, сказать сложно, надо такие вещи вылавливать вовремя и в тестовой лабе обезвреживать. Основная проблема Амазона тут была в том что они игрались на продакшене да еще и в пиковое время, ну и в том что перевызовы не тестировались. А не в том, что _кто-то что-то чуть не то ввел_.)

[АццкоМото]

А то сидит перец и печатает команду "delete critical system X" и как будто так и надо

Unix Way. Думать принято перед тем как нажимаешь Enter, а не в надежде что UI проверит правильность ввода команд.

Я с вами согласен, что Unix way - это когда думать принято очень немного, недолго и неглубоко

[Dmitry67]

А вот Виндовые сервера перегружаются часто, там нет этой проблемы )))

[Dmitry67]

Кстати у меня вопрос
Что если будет создана распределенная система куда будут постепенно добавляться компоненты
А потом выЯснится что зависимость компонент образует цикл
То есть запустить ее с нуля невозможно

[fruit6]

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

[Flash-04]

Кстати у меня вопрос
Что если будет создана распределенная система куда будут постепенно добавляться компоненты
А потом выЯснится что зависимость компонент образует цикл
То есть запустить ее с нуля невозможно

Можно, но с помощью какой-то матери (с)

[zVlad]

вопрос телезрителей "Могло бы такое произойти на Мейнфрейме?"

Я полагаю что в случае с mainframe для решения "an issue causing the S3 billing system to progress more slowly than expected." не понадобилось бы "to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process.".
Если предположить что аналогом "tool to remove capacity" является HMC (Hardware Management Console), то могу сказать что HMC критические операции сопровождает в несколько шагов ("more slowly") и требует ввода пароля a нажатие клавиши "Enter" по умолчанию означает отмену операции, т.е. для выполнения операции нужно подвести указатель на кнопу "Yes" и кликнуть.

[zVlad]

Странно что Амазон строит критические системы на файловой системе с указателями целость которых нужно проверять при холодном старте (после аварийного останова как я понял).
Файловая система zOS/ MVS устроена так что файлы (наборы данных) оккупируют область дисков заданного размера (может быть несколько дисков сразу) и в дальнейшем расширяются заданными кусками (extent) которые можно и отменить. Таким образом холодный старт после аварии системы лишь проверяет были ли завершены операции расширения наборов данных на диске - это проверка одного бита на диске - и если такая операция была прервана, то идет проверка extents всех наборов данных и сопоставление их с данными о свободных участках. Эта проверка позволяет починить диск гораздо быстрее чем в случае блочной файловой системы с цепочками блоков.
Примерно так и надо было поступать Амазону.

[zVlad]

Кстати у меня вопрос
Что если будет создана распределенная система куда будут постепенно добавляться компоненты
А потом выЯснится что зависимость компонент образует цикл
То есть запустить ее с нуля невозможно

Недавно распечатал ибм-скую книжку по zSeries (for dummies. Слабая книжонка, с сильным коммерческим уклоном). Там есть такая фраза мол беда распределенных систем как раз в распределенности и состоит, из нее так сказать вытекает.
Вы, Дима, правильно подметели что с ростом количества конпонент могут быть всякие зацепки так что выход из строя компонета приведет к серии отказов из-за зависимостей, вплодь до оставки всей инфраструктуры. Виртулизации с failover-ами добавляют этот риск, в нас уже были проблемы, и не раз, когда не очень понятно чем вызванный failover приводил к отказу сервиса просто потому что виртуальная то машина поднялась, а вот Оракл на ней нет. Оракл конечно поднимали, но уходило слишком много времени и клиент был недоволен и штрафовал нас. Недавно я рассказывал как мы потеряли деньги на DR TEST основанном на такой технологии.

[uncle_Pasha]

Файловая система zOS/ MVS устроена так что файлы (наборы данных) оккупируют область дисков заданного размера (может быть несколько дисков сразу) и в дальнейшем расширяются заданными кусками (extent) которые можно и отменить. Таким образом холодный старт после аварии системы лишь проверяет были ли завершены операции расширения наборов данных на диске - это проверка одного бита на диске - и если такая операция была прервана, то идет проверка extents всех наборов данных и сопоставление их с данными о свободных участках. Эта проверка позволяет починить диск гораздо быстрее чем в случае блочной файловой системы с цепочками блоков.
Примерно так и надо было поступать Амазону.

zVlad, каков лимит размера дисковой системы у вашего MФ? Сравните это с объемом данных, которые хранит Амазон с S3.
У меня на домашнем компьютере тоже все с пол-пинка перезапускается. Но там всего 24ТБ - сравнимо с вашим МФ, я думаю, и до Амазона - как до Луны пешком.

[zVlad]

Файловая система zOS/ MVS устроена так что файлы (наборы данных) оккупируют область дисков заданного размера (может быть несколько дисков сразу) и в дальнейшем расширяются заданными кусками (extent) которые можно и отменить. Таким образом холодный старт после аварии системы лишь проверяет были ли завершены операции расширения наборов данных на диске - это проверка одного бита на диске - и если такая операция была прервана, то идет проверка extents всех наборов данных и сопоставление их с данными о свободных участках. Эта проверка позволяет починить диск гораздо быстрее чем в случае блочной файловой системы с цепочками блоков.
Примерно так и надо было поступать Амазону.

zVlad, каков лимит размера дисковой системы у вашего MФ? Сравните это с объемом данных, которые хранит Амазон с S3.
У меня на домашнем компьютере тоже все с пол-пинка перезапускается. Но там всего 24ТБ - сравнимо с вашим МФ, я думаю, и до Амазона - как до Луны пешком.

С какого перепуга 24ТБ может быть сравнимо типичным размером дисков на МФ?
Вы давно меня читаете и должны бы помнить что никаких дисков в собственно МФ нет (не считая SSD для страничной памяти в последних моделях). Диски подключаются внешние и их может быть столько сколько нужно и сколько может себе позволить владелец.
Дисковые подсистемы нынче используются одни и теже что для МФ что для серверов других платформ. В этом разницы нет. Разница есть в том что прочие сервера, поскольку их много, подключаются к дискам через свитчи, а МФ без свитчей (свитчи используются для удаленного подключения и для мироринга).
Приэтом один МФ может иметь несколько сотен каналов ввода-вывода. Количество различаемых дисков 65536 на каждую из нескольких CSS - channel subsystem. Каждый диск раньше, давным давно, имел модельное ограничение размера. Например у нас используются диски ~10ГБ. Даже в этом случае для 24ТБ нужно всего 2400 дисков, а по максимуму на одну CSS получается 650 ТБ (если я не ошибся в вычислениях). И это если использовать модель с 10 ГБ. Но с введением модели с расширенной адресацией (это где-то начало 2000) размер диска (каждого из 65536 per CSS) может быть каким угодно большим (с ограничением конечно, но намного больше 10ГБ).
Вот и считайте сколько дисков может быть на одном МФ. Всего лишь на одном.

[zVlad]

Дядя Паша, наша конкретная установка МФ имеет 50ТБ дисков. Но что это за МФ? Это 4 активных кора с установленной мощностью в шкале от A до Z на букве О. RAM 32 GB. это не только Production, но и вообще все инстансы ERP приложения компании с 10 тысячами сотрудников. Это и БД бизнес логика, все в одном.
При этом по дискам мы очень далеки от пределов. Мы даже не используем модель дисков с расширенной адресацией, обходимся моделью, наверное начала 90-х годов.
Мы не знаем сколько дисков у Амазон s3. И сколько серверов эти диски качает.

[Kolbasoff]

zVlad, каков лимит размера дисковой системы у вашего MФ? Сравните это с объемом данных, которые хранит Амазон с S3

Мне cloud scalability нравиться, когда правильно сконфигурена. Трафик ритэйла в сезон распродаж в 5 раз больше чем в мертвый сезон. Трафик от банков сильно больше в день получки, и есть дни когда совпадают дни получки для контракторов и фултаймеров когда трафик в 10 раз больше чем в обычные дни. У телевизионщиков трафик в праймтайм. Грамотно сконфигуренное облако рентует больше ресурсов у Амазона в момент нагрузки и отдает в момент расслабухи. Грамотно написанные программы запускают только те сервисы/пакетники которые нужны в данный момент. МФ и суперкомп хороши если нагрузка ровная и известная. Например, для обсчета телеметрии от радиотелескопа или от спутников. Сконфигурили утилизацию 50%, посадили парочку админов типа "накорми собак и ничего не трогай", и нормально.

[zVlad]

zVlad, каков лимит размера дисковой системы у вашего MФ? Сравните это с объемом данных, которые хранит Амазон с S3.
У меня на домашнем компьютере тоже все с пол-пинка перезапускается. Но там всего 24ТБ - сравнимо с вашим МФ, я думаю, и до Амазона - как до Луны пешком.

Полистав мануалы насчет лимитов на МФ я насчитал что на нашем более чем скромном мф образца 2013 года и с версией zOS неподдерживаемой ИБМ с сентября прошлого года я могу сконфигурировать, а значит и использовать, больше 60 000 ТБ. Это следует из того что максимум дисков на единственную нашу CSS равен 65536, а максимальный размер диска (логического) -1 ТБ.
Сейчас у нас примерно 50 ТБ используется на нашем мф.

[zVlad]

..... МФ и суперкомп хороши если нагрузка ровная и известная. Например, для обсчета телеметрии от радиотелескопа или от спутников. Сконфигурили утилизацию 50%, посадили парочку админов типа "накорми собак и ничего не трогай", и нормально.

Абсолютно неверное представление. Начиная с того что МФ и суперкомп это две большие разницы.
Подробней я, в сотый наверное раз, попытаюсь разъяснить позже, а пока ограничусь тем что в пиковые часы наш МФ нагружается, по CPU, на 100%. Ввод-вывод никогда не превышает 10% загрузки.

[zVlad]

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

[Kolbasoff]

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

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

[zVlad]

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

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

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

[Kolbasoff]

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

Амазон довел до совершенства обезличивание рабочей массы. При этом все работает на удивление хорошо, по сравнению с пропраеторными инфрастуктурами.

[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 таких инстансев.