Демократизация мейнфреймов

[StrangerR]

всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны

Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...

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

[iDesperado]

Еще интересная статья и несколько иной взгляd на результаты МФ по поводу этих тестов:

http://www-03.ibm.com/support/techdocs/ ... x/WP101861


Обратите внимание на четвертый тест.

ну вот. документ отвечает практически на все вопросы которые нас интересовали.
in January of 2010 the same benchmark was executed in order to compare the performance of the two servers. The same DB2 subsystem (V8.1 NFM) was used, the same PeopleTools version, the same IBM System Storage DS8300 and the same benchmark kit, even the same JCL was used to run the processes.
значит эти результаты уже не получиться списать на криворукого оракла который не умеет zOS готовить. согласны ? этот тест уже делал сам IBM, ну и что мы имеем в результате (беру цифры из тест 4, z10 EC with 6 Engines):
Paysheet Creation: 4 на МФ против 3.5 на М5000
Payroll Calculation: 24.53 на МФ против 23.78 на М5000
Payroll Confirmation: 24.8 на МФ против 22.83 на М5000

и кстати теперь понятно кто делал бенчмарки, делали IBM Oracle International Competency Center in Pleasanton, CA. т.е. делались с привлечением спецов от IBM.
вот их описание
http://public.dhe.ibm.com/common/ssi/ec ... 96USEN.PDF

[Dmitry67]

всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны

Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...

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

Как это не нужна?
Если snapshot MDF/LDF не crash-consistent, то при восстановлении вы получите фигу.
Если вам везло до сих пор, то это не навсегда.

[zVlad]

Еще интересная статья и несколько иной взгляd на результаты МФ по поводу этих тестов:

http://www-03.ibm.com/support/techdocs/ ... x/WP101861


Обратите внимание на четвертый тест.

ну вот. документ отвечает практически на все вопросы которые нас интересовали.
in January of 2010 the same benchmark was executed in order to compare the performance of the two servers. The same DB2 subsystem (V8.1 NFM) was used, the same PeopleTools version, the same IBM System Storage DS8300 and the same benchmark kit, even the same JCL was used to run the processes.
значит эти результаты уже не получиться списать на криворукого оракла который не умеет zOS готовить. согласны ? этот тест уже делал сам IBM, ну и что мы имеем в результате (беру цифры из тест 4, z10 EC with 6 Engines):
Paysheet Creation: 4 на МФ против 3.5 на М5000
Payroll Calculation: 24.53 на МФ против 23.78 на М5000
Payroll Confirmation: 24.8 на МФ против 22.83 на М5000

и кстати теперь понятно кто делал бенчмарки, делали IBM Oracle International Competency Center in Pleasanton, CA. т.е. делались с привлечением спецов от IBM.
вот их описание
http://public.dhe.ibm.com/common/ssi/ec ... 96USEN.PDF

Нет не согласен. Перечисленное (The same) вовсе не отражает тех вопросов от которых может сильно зависить результат тестирования. Мне нужно гораздо больше данных чтобы убедиться что все было сделано как следует.
Особенно подозрительным мне кажется постоянство выполнения теста в 8 потоков, что на МФ с 6 CPU, что на 9 CPU.
Непонятен тест 2:

Test two
Table 3 shows the results of a second test where all processes were run single threaded. This process basically reduces the number of CPUs required for the process to one. As a result the much faster z10 EC server far outperformed the much slower z990 as is shown by the following results. The number of employees processed was the same but all processes were run in a single job.

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

Непонятны выводы из результатов теста 4:

Paysheet actually ran a little faster on 6 engines, but Paycalc and Payconfirm both showed ever so slight improvements of about 9%. Clearly the 6 engine configuration is a better choice for this workload than the 9-way configuration from a price/performance perspective.

6 CPU дают тот же результат что и 9 СPU и этому не дается никаких объяснений, лишь радостно заявляется что 6 CPU дешевле чем 9. Это и без теста понятно. А что будет с 4 CPU, например?

Summary, тоже не о чем. Вообщем боюсь я что этот Mike, контакты с которым я запросил у ИБМ, такой же графоман, как я уже много видел и слышал. Они кичаться годами своего стажа, а копнешь немного и там пусто. Но не будем торопиться с окончательными выводами. Попробуем докопаться до истины.

[iDesperado]

Мне нужно гораздо больше данных чтобы убедиться что все было сделано как следует.
Особенно подозрительным мне кажется постоянство выполнения теста в 8 потоков, что на МФ с 6 CPU, что на 9 CPU.

а по моему тут все совершенно ясно

6 CPU дают тот же результат что и 9 СPU и этому не дается никаких объяснений

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

Вообщем боюсь я что этот Mike, контакты с которым я запросил у ИБМ, такой же графоман, как я уже много видел и слышал. Они кичаться годами своего стажа, а копнешь немного и там пусто.

Mike графоман, IBM Oracle International Competency Center невежествены, а реальную систему у клиента конечно же будет настраивать д'Артоньян.

Но не будем торопиться с окончательными выводами. Попробуем докопаться до истины.

отлично, было бы здорово поглядеть подробности. особенно ожидания на i/o

[StrangerR]

всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны

Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...

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

Как это не нужна?
Если snapshot MDF/LDF не crash-consistent, то при восстановлении вы получите фигу.
Если вам везло до сих пор, то это не навсегда.

Да снапшот он всегда креш консистент, если конечно сама ВМваре не кривая. СИстема то встает после выключения питания - значит и с снапшота встанет. А заморочки там связаны с тем что там пытаются сделать не просто креш консистент снапшот а еще и сбросить кэш и сделать чекпойнт в базе данных - и для этого вызывают скрипт через VMware tools, и вот тут бывают конфликты. Но оно и без этого скрипта получается вполне себе крэш консистент, просто делаем снапшот момента времени и все...

Пошел смотреть ваш тест, но в целом уже понятно что он ни о чем. Интересно то было сравнить именно МФ с апплаенсом - МФ с прямой ДБ2 с Оракле ДБ машиной и стоящим рядом приложеинием. А так - ну показали что две железки практически одинаковы по скорости, и что с того следует?

[Dmitry67]

При крахе - да
А при бэкапе живого диска он разные части диска в разные моменты времени
Значит либо нужен LOG, как это делает SQL, либо должен держать все изменения на период пока бэкап начался, но еще не закончился в памяти

[Zombie416]

А при бэкапе живого диска он разные части диска в разные моменты времени
Значит либо нужен LOG, как это делает SQL, либо должен держать все изменения на период пока бэкап начался, но еще не закончился в памяти

Кмк, проблема не в том что разные части диска в разные моменты времени бэкапятся. Это было бы слишком просто починить, тем более что любой более-менее приличный hypervisor умеет делать снапшоты, делать лог изменений после снапшота, и потом на снапшот откатываться. Естессно надо бэкапить и память, и диски одновременно.

Проблемы начинаются когда VM больше чем одна. Нужно по-крайней мере сообщать приложениям внутри VM, после restore, чтобы они откатили все pending transactions (т.к. эти transactions будут сильно устаревшими в момент восстановления). Плюс в кластерных решениях (даже в сравнительно несложных вроде domain controllers) snapshot одного контроллера приведет к неприятным последствиям в смысле синхроницации.

Т.е. с бэкапом проблем нет. Есть проблемы с восстановлением потом

[StrangerR]

А при бэкапе живого диска он разные части диска в разные моменты времени
Значит либо нужен LOG, как это делает SQL, либо должен держать все изменения на период пока бэкап начался, но еще не закончился в памяти

Кмк, проблема не в том что разные части диска в разные моменты времени бэкапятся. Это было бы слишком просто починить, тем более что любой более-менее приличный hypervisor умеет делать снапшоты, делать лог изменений после снапшота, и потом на снапшот откатываться. Естессно надо бэкапить и память, и диски одновременно.

Проблемы начинаются когда VM больше чем одна. Нужно по-крайней мере сообщать приложениям внутри VM, после restore, чтобы они откатили все pending transactions (т.к. эти transactions будут сильно устаревшими в момент восстановления). Плюс в кластерных решениях (даже в сравнительно несложных вроде domain controllers) snapshot одного контроллера приведет к неприятным последствиям в смысле синхроницации.

Т.е. с бэкапом проблем нет. Есть проблемы с восстановлением потом

Простите, вы о чем? Имейдж бэкап делается через Vmware и первое что она делает это делает снапшот дисков. На уровне самой VMware то есть ей до фени какая там операционка и какие фиговины в этой операционке установлены. Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена (с чем связано множество глюков, кстати), она просто немного помогает ускорить старт восстановленной системы. Ну и туда же засунута контрольная точка в MS SQL которая правда ни хрена не пашет на многих системах в этом виде - приходится выключать (при восстановлении произойдет DB recovery ну и фиг с ним...)

Когда VM больше чем одна - то конечно, но на эту тему мы делаем независимо бэкапы данных и дальше при восстановлении в DR я синхронизую базу и файлы - при бэкапе файловой системы с документами туда пишется файл с временем, а при восстановлении это время используется чтобы восстановить базу именно на этот момент времени. Но эта история с восстановлением группы систем вылезет при любом методе бэкапов, кроме разве что _бэкапим весь вольюм на SAN системе_.

PS. Кластеры это гемморой по определению. Тут спору нету. Я так и не смог кстати заставить линуксные системы распознать что они были _Suspended_ - в итоге кластерные системы нельзя двигать онлайн или саспендить. Но это все ожидаемо и кстати слабо относится к мейнфреймовому спору.

[crypto5]

А при бэкапе живого диска он разные части диска в разные моменты времени

А copy on write нельзя снапшот реализовать? Я думал все снапшоты так и делают уже много лет.

[StrangerR]

А при бэкапе живого диска он разные части диска в разные моменты времени

А copy on write нельзя снапшот реализовать? Я думал все снапшоты так и делают уже много лет.

Естественно, причем зачастую (vmware) не copy on write а просто дополнительная копия изменений. В итоге в VMware
снапшот идет мгновенно, реверт то снапшот идет мгновенно, а удаление снапшота занимает заметное время.

[Zombie416]

Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена

А вот кстати, зачем эта опция нужна? С кластерами и бэкапом VM - фундаментальная проблема, которую с переменным успехом можно подвязывать веревочками хитроумными способами извещения приложений внутри VM о том что их бэкапят-восстанавливают, всякие синхронизации наружного и внутреннего VSS (в случае Windows/Hyper-V), и т.д.

Но в случае одной VM без distributed transactions, если есть бэкап snapshot-а, т.е. памяти И дисков, то все недописанные буфера-кеши-транзакции, по идее, при восстановлении должны вернуться в исходное состояние, и дописаться/отвалиться по таймауту/и т.д. Зачем буфера сбрасывать?

[StrangerR]

Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена

А вот кстати, зачем эта опция нужна? С кластерами и бэкапом VM - фундаментальная проблема, которую с переменным успехом можно подвязывать веревочками хитроумными способами извещения приложений внутри VM о том что их бэкапят-восстанавливают, всякие синхронизации наружного и внутреннего VSS (в случае Windows/Hyper-V), и т.д.

Но в случае одной VM без distributed transactions, если есть бэкап snapshot-а, т.е. памяти И дисков, то все недописанные буфера-кеши-транзакции, по идее, при восстановлении должны вернуться в исходное состояние, и дописаться/отвалиться по таймауту/и т.д. Зачем буфера сбрасывать?

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

[Dmitry67]

Да, судя по всему.
У нас она была включена, SQL серваре писали свое I/O suspended... I/O resumed в логи.
В как то вскоре после этого они почему то часто бывали в каком то оглушенном состоянии - рвали коннекции, жаловались на ошибки I/O...
Убрали это - все стало как по маслу.

[zVlad]

нашел убийственный аргумент. тесты реальной задачи. Peoplesoft
http://www.oracle.com/us/solutions/benc ... 67486.html

Итак берем 9-way z10 EC 2097-709 c DS8300 (6512 MIPS) проиграл 8-way SPARC Enterprise M5000 (32 cores) с флеш сториджом. причем заметно проиграл 87.4 минуты, против 50.11 минут. базы совершенно одинаковы, задача совершенно одинакова. у МФ было 8 потоков, у M5000 32.

8-way SPARC Enterprise M5000 (32 cores)
http://www.oracle.com/us/media1/ps9-na- ... 078501.pdf

9-way z10 EC 2097-709 c DS8300
http://www.oracle.com/us/solutions/benc ... 366176.pdf
....

Подытожим тесты, оставив пока вопрос об аккуратности постановки теста на МФ за скобками - диалог с Майком еще не закончен.

Вы не достаточно внимательно изучили предложенные Вами репорты, хотя там всего пять страниц в каждом включая булшир.
Во-первых, как я уже сообщал кроме UNICODE теста там есть данные без UNICODE и согласно этим данным время МФ не 87.4, а 58,96. Вот этот репорт:

http://www.oracle.com/us/solutions/benc ... 166431.pdf

Во-вторых, количество коров в тесте на МФ было не 9, а 8 следовательно MIPS не 6512, а 8/9 от этого числа. RAM на МФ - 24 GB. Соответствующие параметры у М5000 - 32 (правда на меньшей частоте 2.53 против 4.4 у МФ). RAM 64 GB.
В-третьих, Вы почему то привели только результаты одного из трех тестов проделанных в обоих случаях. Понятно почему - потому что Оракл привел их на первой страницы как "Summary of Results" и привел Оракл только результат одного - первого - теста, по которому у меня основные и очевидные претензии - этот тест на пераллельную обработку и в этом тесте необоснованно занижено количество потоков на МФ до 8-ми, в то время как на M5000 их было 32. Я добъюсь от Майка по крайней мере объяснения этому феномену.
Другие два теста дали следущие результаты:

Тест2:

М5000 - 512.95 минут
2097-709 - 230.57 минут

Тест 3:

М5000 - 884.91 минуты
2097-709 - 340.4 минуты

Да и еще у нас остается финансовый вопрос. Вот что пишет Майк о том чем загружен это МФ в Оракл в свободное от тестов время:

http://www-03.ibm.com/support/techdocs/ ... 092010.pdf

Today’s System z Environment at PeopleSoft
- z10 EC model 709 with 9 general processors, 7 IFLs, 4 zIIPs and 1 coupling facility with
384 GB memory.
- DS8300 with 9 TB, multiple DS6800s
- 7 LPARs
• z/VM 5.4 running the z/Linux environment for test and development
• z/VM 5.4 running the z/Linux environment for benchmarking
• z/VM 5.4 running 15 z/OS images (1.6, 1.7, 1.8,1.9, 1.10 and 1.11) running the test,
development and support systems
• z/VM 5.4 running 14 z/OS images (1.6, 1.7, 1.8,1.9, 1.10 and 1.11) running the test,
development and support systems
• z/OS 1.10 running the benchmark environment
• z/OS 1.10 running the build systems
• z/OS 1.10 running system test
- Over 100 DB2 subsystems
• DB2 V7, V8 and V9
• DB2 V10 Beta initial testing underway