С другой стороны, у VMWare есть гораздо более серьезное ограничение - максимум 8 процессоров на гостевую машину.StrangerR wrote:Статья интересная в первой половине. А потом начинаются сплошные передергивания:
- Vmware 20 VM per CPU - нету там такого ограничения, даже на бесплатной ESXi
а теперь сравните с SAP на x86zVlad wrote:Мы, имея лишь одну тысячу MIPS крутим ERP приложение для клиента с более чем 10000 работников, БД более 1 TB и аппликэйшн OLTP сервером. Это приложение у клиента основное в их ИТ. Плюс многие другие приложения не на МФ либо непосредственно обращаются к МФ БД, либо используют онлайн реплику БД, apply часть которой на том же МФ выполняется. Т.е. это целая комплескная инфраструктура и все на одном МФ с 1000 MIPS и девелопмент и QA и трэйниг и сандбохы, т.е. абсолютно все кроме DR.
От ИБМ нашел (результаты рекордные в http://www.spec.org/virt_sc2010/results ... _perf.html, IBM x3850 X5 ) для KVM @ RHEL6: 6 TB RAM, 256 threads, 64 vCPUs per guest, 6 TB Max Memory Per Guestuncle_Pasha wrote:С другой стороны, у ВМШаре есть гораздо более серьезное ограничение - максимум 8 процессоров на гостевую машину.StrangerR wrote:Статья интересная в первой половине. А потом начинаются сплошные передергивания:
- Vmware 20 VM per CPU - нету там такого ограничения, даже на бесплатной ESXi
Удачи!
zVlad wrote:Чтобы перейти от пустопорожней болтовни и препирательств я послал запрос ИБМ (через службу поддержки ИБМ) с двумя вопросами по поводу "Oracle PeopleSoft Benchmark White Papers":
1. Участвовал ли ИБМ в этих тестах, и
2. Согласен ли ИБМ что в оракловских тестах на ИБМ МФ было сделано все чтобы показать на что способен ИБМ МФ в данном случае.
А пока, закончил я свой запрос, z10 EC 2097-709 выглядит хуже чем SUN SPARC M5000.
Буду держать вас в курсе этого диалога с ИБМ.
Диалог еще продолжается, мне было обещанно попытаться найти больше или найти более правильный контакт.....
I didn't find any official IBM comments, but it was interesting reading. Very lively ... IBM would not have been involved in the oracle benchmarks. As far as any tuning of the database, indexes etc. There is nothing in the notes to say that anything was done. Whether they did any db2 z/OS specific tuning I would have no way of knowing. Partitioning, parallelism, zIIPs etc.. The only thing I am aware of is that occasionally we get customers with poor performing oracle queries, and we have made tuning suggestions.. mostly additional runstats to help with access path selection.. that sort of thing. Hopefully this helps a bit..
....
Нетflip_flop wrote:Вопрос по 3) - так ли это важно на практике иметь большее число ВМ? Это имеет смысл только для задач интенсивного ввода-вывода или еще где-то?
Они lже плодятся как кролики. У меня только в двух основных зонах около 100 ВМ-ок. А в зоопарке тестового рака - я даже и не знаю, там не совсем мое хозяйство, но если там штук 10 ESXi и на каждой штук по 20 - 30 VM-ок (на глаз) то можно прикинуть общее количество. А главное, этот зверь как кролик - плодится со страшной скоростью. К примеру в одном проекте - главная система (8 HW), стейджинг (8 VM) девелопмент (2 VM) DR девелопмено (2 VM) - и это только в дата центре, а сколько в тестовом центре в офисе живет я даже боюсь посчитать... говорю же, как кролики...Dmitry67 wrote:Нетflip_flop wrote:Вопрос по 3) - так ли это важно на практике иметь большее число ВМ? Это имеет смысл только для задач интенсивного ввода-вывода или еще где-то?
У нас 300-400 VM (под клиента машинки BL, DB, иногда QA BL, QA DB)
VMware объединяет Blades в Datacenters. Даже если Blade тянят ограниченное количество VM, ничто не мешает взять например штук 10 blades. VMware может гонять VM не останавливая их между physical boxes. Можно любой из них отправить на ремонт, выгнав временно VMки оттуда - так даже удобнее.
Я еще не приступил к чтению статьи, но по поводу пунктов 1 и 2 могу сказать что мне такие мысли приходили в голову. И эти мысли были навеяны дискуссией в этой теме, а именно предоставленными данными о том как далеко шагнули сервера на х86-64. Кстати, такая ситуция уже имела место быть в истории компьютеров. Это когда исчезли PDP(DEC) и почти изчезли VAX. Их тогда тоже скушали бурно растущие мини-компьютеры. Тогда еще был термин супер-мини. И тогда тоже МФ выстояли.flip_flop wrote:А вообще интересно, господа ИТ-шники - в вышеприведенной статье от zVlad 3 вывода (на первый взгляд):
1) SPARC & Itanium - RIP, long live x86_64, Power, MF
2) В будущем предвидится 2 основные линии - гомогенные х86_84 и гетерогенные x86_64+Power+MF
3) целесообразность сохранения [Power & MF] обьясняется их возможностью иметь больше ВМ на ЦПУ чем х86_64
Вопрос по 3) - так ли это важно на практике иметь большее число ВМ? Это имеет смысл только для задач интенсивного ввода-вывода или еще где-то?
StrangerR wrote:Наличие И партишенов И ВМ в МФ является на самом деле очень большим плюсом. А минусом является отсутствие дешевой начальной конфигурации - сервер размером 2U, с терабайтом диском, ценой до $10K, и чтобы там была та же самая ОС и те же самые процессоры что и на вашем МФ. Пока этого не будет - ниша МФ будет очень маленькой.
Реальные проекты для чего угодно всегда начинаются с чего то небольшого. Люди привыкают. И потом когда надо увеличиваться - уже не идут на большое. Оракл на эти грабли уже наступил и уступил приличный кусок маркета MS SQL именно из за низкой ступеньки входа. МФ маркет уступили именно из за высокой ступеньки входа.zVlad wrote:StrangerR wrote:Наличие И партишенов И ВМ в МФ является на самом деле очень большим плюсом. А минусом является отсутствие дешевой начальной конфигурации - сервер размером 2U, с терабайтом диском, ценой до $10K, и чтобы там была та же самая ОС и те же самые процессоры что и на вашем МФ. Пока этого не будет - ниша МФ будет очень маленькой.
В принципе это легко решается эмулятором Hercules или подобным. А также это может быть легко решено путем аренды времени виртуальной машины(машин).
Но скорее всего Ваши требования к начальной конфигурации МФ - это просто привычные Вам проекты и требования к ним. Реальные проекты для МФ совсем в другом диапазоне цен существуют.
Еще интересная статья и несколько иной взгляd на результаты МФ по поводу этих тестов:iDesperado wrote:нашел убийственный аргумент. тесты реальной задачи. 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
....
Да никаких мыслей не навевают, потому что я эти песни знаю отлично. Все очень красиво, первый год. Через 4 года вы остаетеся с железкой примерно сравнимой с ноутбуком начальника по скорости при цене в 1000 раз более высокой.zVlad wrote:Касательно виртуальных машин есть много отличий в преминимости и значении этой технологии на МФ и х86. Например, для х86 появление ВМ позволило ссохранить смысл роста производительности серверов х86. В том смысле что без ВМ врядли было бы возможным загрузить такие моща одним инстанцем Виндов. Он бы не потянул. МА МФ иначе. НА МФ есть zOS который может сколько угодно нагрузки тянуть одним инстанцем. Следовательно ВМ для МФ не так уж и принципиален.
Другие отличия BМ МФ от ВМ х86 хорошо видны из таблицы в статье "OPINION..." from Clabby Analytics. Интересно послушать что думают представители с х86 об этой сравнительной таблице. Какие мысли она вам навевает?
Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...StrangerR wrote: всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны
Ну не знаю, у меня они во первых уживаются, а во вторых, эта крэш консистенси нафиг не нужна - снапшота достаточно по жизни потому что давно уже базы и прочее сами по себе крэш консистент. Они (синки перед снапшотами) просто уменьшают время восстановления бэкапа. Я их выключаю просто, если почему то не идут, по жизни ни на что не повлияло сильно. Ну и бэкапы базы данных тоже остаются.Dmitry67 wrote:Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...StrangerR wrote: всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны
ну вот. документ отвечает практически на все вопросы которые нас интересовали.zVlad wrote: Еще интересная статья и несколько иной взгляd на результаты МФ по поводу этих тестов:
http://www-03.ibm.com/support/techdocs/ ... x/WP101861
Обратите внимание на четвертый тест.
Как это не нужна?StrangerR wrote:Ну не знаю, у меня они во первых уживаются, а во вторых, эта крэш консистенси нафиг не нужна - снапшота достаточно по жизни потому что давно уже базы и прочее сами по себе крэш консистент. Они (синки перед снапшотами) просто уменьшают время восстановления бэкапа. Я их выключаю просто, если почему то не идут, по жизни ни на что не повлияло сильно. Ну и бэкапы базы данных тоже остаются.Dmitry67 wrote:Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...StrangerR wrote: всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны
iDesperado wrote:ну вот. документ отвечает практически на все вопросы которые нас интересовали.zVlad wrote: Еще интересная статья и несколько иной взгля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
На кой люд тестировать нагрузку заведомо не приемлемую на МФ. Никто никогда такой нагрузка не интересовался в реальных продакшн системах.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.
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.
а по моему тут все совершенно ясноzVlad wrote:Мне нужно гораздо больше данных чтобы убедиться что все было сделано как следует.
Особенно подозрительным мне кажется постоянство выполнения теста в 8 потоков, что на МФ с 6 CPU, что на 9 CPU.
затык в и/о, поэтому и добавление CPU ничего не дает. поэтому и добавление новых потоков ничего не дадут. 8 потоков уже упираются в и/о, смысла добавлять новые абсолютный ноль.zVlad wrote:6 CPU дают тот же результат что и 9 СPU и этому не дается никаких объяснений
Mike графоман, IBM Oracle International Competency Center невежествены, а реальную систему у клиента конечно же будет настраивать д'Артоньян.zVlad wrote:Вообщем боюсь я что этот Mike, контакты с которым я запросил у ИБМ, такой же графоман, как я уже много видел и слышал. Они кичаться годами своего стажа, а копнешь немного и там пусто.
отлично, было бы здорово поглядеть подробности. особенно ожидания на i/ozVlad wrote:Но не будем торопиться с окончательными выводами. Попробуем докопаться до истины.
Да снапшот он всегда креш консистент, если конечно сама ВМваре не кривая. СИстема то встает после выключения питания - значит и с снапшота встанет. А заморочки там связаны с тем что там пытаются сделать не просто креш консистент снапшот а еще и сбросить кэш и сделать чекпойнт в базе данных - и для этого вызывают скрипт через VMware tools, и вот тут бывают конфликты. Но оно и без этого скрипта получается вполне себе крэш консистент, просто делаем снапшот момента времени и все...Dmitry67 wrote:Как это не нужна?StrangerR wrote:Ну не знаю, у меня они во первых уживаются, а во вторых, эта крэш консистенси нафиг не нужна - снапшота достаточно по жизни потому что давно уже базы и прочее сами по себе крэш консистент. Они (синки перед снапшотами) просто уменьшают время восстановления бэкапа. Я их выключаю просто, если почему то не идут, по жизни ни на что не повлияло сильно. Ну и бэкапы базы данных тоже остаются.Dmitry67 wrote:Небольшая ложечка дегтя: я тоже считал что бжкапы должны идти независимо ни от чего, что внутри виртуалки. Тем не менее например Symantec Backup Agent должен быть снесен с виртуалки, чтобы работали snapshot crash-consistent backups. С SQL тоже есть тонкости...StrangerR wrote: всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны
Если snapshot MDF/LDF не crash-consistent, то при восстановлении вы получите фигу.
Если вам везло до сих пор, то это не навсегда.
Кмк, проблема не в том что разные части диска в разные моменты времени бэкапятся. Это было бы слишком просто починить, тем более что любой более-менее приличный hypervisor умеет делать снапшоты, делать лог изменений после снапшота, и потом на снапшот откатываться. Естессно надо бэкапить и память, и диски одновременно.Dmitry67 wrote:А при бэкапе живого диска он разные части диска в разные моменты времени
Значит либо нужен LOG, как это делает SQL, либо должен держать все изменения на период пока бэкап начался, но еще не закончился в памяти
Простите, вы о чем? Имейдж бэкап делается через Vmware и первое что она делает это делает снапшот дисков. На уровне самой VMware то есть ей до фени какая там операционка и какие фиговины в этой операционке установлены. Там есть опция _включать или нет сброс буферов из самой системы_ причем по умолчанию она включена (с чем связано множество глюков, кстати), она просто немного помогает ускорить старт восстановленной системы. Ну и туда же засунута контрольная точка в MS SQL которая правда ни хрена не пашет на многих системах в этом виде - приходится выключать (при восстановлении произойдет DB recovery ну и фиг с ним...)Zombie416 wrote:Кмк, проблема не в том что разные части диска в разные моменты времени бэкапятся. Это было бы слишком просто починить, тем более что любой более-менее приличный hypervisor умеет делать снапшоты, делать лог изменений после снапшота, и потом на снапшот откатываться. Естессно надо бэкапить и память, и диски одновременно.Dmitry67 wrote:А при бэкапе живого диска он разные части диска в разные моменты времени
Значит либо нужен LOG, как это делает SQL, либо должен держать все изменения на период пока бэкап начался, но еще не закончился в памяти
Проблемы начинаются когда VM больше чем одна. Нужно по-крайней мере сообщать приложениям внутри VM, после restore, чтобы они откатили все pending transactions (т.к. эти transactions будут сильно устаревшими в момент восстановления). Плюс в кластерных решениях (даже в сравнительно несложных вроде domain controllers) snapshot одного контроллера приведет к неприятным последствиям в смысле синхроницации.
Т.е. с бэкапом проблем нет. Есть проблемы с восстановлением потом
А copy on write нельзя снапшот реализовать? Я думал все снапшоты так и делают уже много лет.Dmitry67 wrote: А при бэкапе живого диска он разные части диска в разные моменты времени