s3 outage details posted

[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]

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

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