С другой стороны, у 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: всякие там бэкапы - поскольку бэкапятся имейджи, то бэкапы теперь уже независимы от ОС и можно держать системы как они есть и пока они нужны