Партиция с максимальными ресурсами?

Главная Форумы POWER Systems Виртуализация POWER Партиция с максимальными ресурсами?

В этой теме 24 ответа, 8 участников, последнее обновление  Дмитрий 9 года/лет, 5 мес. назад.

  • Автор
    Сообщения
  • #1967

    Sever
    Участник

    Если это не противоречит “политике партии” , то просьба дать такую инфу…
    Какие ресурсы (процессоры, память оперативная и дисковая) у уважаемых юзеров портала в самой большой партиции? Какая загрузка процессоров на ней в пиковое время?

    Мне это нужно для сравненительной характеристики работы сред p и i.

    Заранее благодарю.

  • #1975

    Дмитрий
    Участник

    Можно поточнее вопрос задать (к чему он)?

    Чтобы это не было воспринято многоуважаемой аудиторией как вопрос из серии “Кто всех круче” (помнится, было такое развлекалово в разделе “Всякая…”).

  • #1977

    _KIRill
    Хранитель

    И, кстати, deadfalcon (участник портала, который всю ту хохму затеял) пропал куда-то. Может быть его затянуло в сервисный процессор? 🙂

    ---As If, But Not---

  • #1978

    Sever
    Участник

    Dmitry писал(а):

    Можно поточнее вопрос задать (к чему он)?

    Меня интересует – есть ли в России “большие” (от 16 и более процессоров) партиции на AIX с большой вычислительной мощностью. Если есть, то какова их функциональная нагрузка???

  • #2005

    andrewk
    Участник

    а есть ли смысл в таких больших партициях?

  • #2006

    Дмитрий
    Участник

    andrewk, в одном ооочень-большом-банке (по российским меркам), такие используются. И не в одном!

  • #2009

    andrewk
    Участник

    Dmitry, я тоже знаю один очень-большой-банк, в котором используются такие партиции, но с dedicated cpu и под i5/OS 😉

  • #2034

    Дмитрий
    Участник

    Есть под AIX.
    Кстати, на POWER5, POWER6 в любом случае гипервизор работает, т.о. AIX работает в “партциии” 🙂

    Только, похоже, никто сюда не пишет – все заняты сравнением производительности…

  • #2102

    Sever
    Участник

    andrewk писал(а):

    а есть ли смысл в таких больших партициях?

    все говорят о виртуализации и консолидации, – утопия это, зачем усложнять методом создания тесных клетушек из “маленьких” партиций?
    берется одна партиция и все располагается на ней – один большой “котел”
    преимущества:
    легче сопровождать;
    легче наращивать ввод/ввод вывод;
    производительность системы в любой момент времени почти неограничена;
    апгрейдить легко.

  • #2103

    Dmitry
    Участник

    sever писал(а):

    все говорят о виртуализации и консолидации, – утопия это, зачем усложнять методом создания тесных клетушек из “маленьких” партиций?
    берется одна партиция и все располагается на ней – один большой “котел”
    преимущества:
    легче сопровождать;
    легче наращивать ввод/ввод вывод;
    производительность системы в любой момент времени почти неограничена;
    апгрейдить легко.

    В одном из телекомов так и сделано
    СтоИт p5 595 (48CPU/>200GB RAM) в single system image и крутит около 20-ти оракловых инстансов с централизованным биллингом

  • #2104

    _KIRill
    Хранитель

    берется одна партиция и все располагается на ней – один большой “котел”

    Категорически не согласен.
    Для начала предлагаю ознакомиться с https://www.aixportal.ru/content/view/188/1/.

    ---As If, But Not---

  • #2105

    Sever
    Участник

    В теории все красиво, но представим на минуту, что цель достигнута – вы в один большой сервер смигрировали все основные, неосновные и все прочие сервисы. Все даже работает….
    Вы имеете ВСЕ в одной коробке. Допустим 40 партиций на 595ой. Все партиции 24*7 и взаимосвязаны по данным между собой.

    Объясните на примере, что вы будете делать при неплановом останове этого сервера – погорела половина процессорных нод и или полностью накрылся сторадж 8300 из-за кривого микрокода? Вы ж ни в жисть не обеспечите доступность этих сервисов даже при наличии второй резервной машины.

    Что будем делать, когда вся эта централлизованная гора железа выйдет из строя?

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

    Может не надо все яйца лОжить в одну корзину ???

  • #2106

    _KIRill
    Хранитель

    Так, давайте по пунктам. Для начала представим что есть некий заказчик купивший одну p595 (без CoD процессоров и памяти) и один DS8300 (то что за продажу такого “решения” надо увольнять без права заниматься IT в течении 10 лет промолчим). И мне надо “обеспечить”. Обеспечу. Для начала, перед вводом в промышленную эксплуатацию комплекса, необходимо разработать План. План спасения в случае Большого Глюка.
    План. 40 боевых LPAR на 595. Некое количество LPAR (назовём их STBL)c минимальным набором ресурсов (CPU 0.1, RAM 192 (дабы AIX стартовать смог)). И HACMP. Падает часть боевых LPAR. HACMP STBL эту ситуацию обнаруживают. Запускаются DLPAR операции, и в зависимости от количества доступных ресурсов меняются ресурсы принадлежащие STBL. На STBL стартуют приложения. Downtime – минуты 3. Может 5.
    Уважаемый sever (к сожалению не знаю вашего Имени), я полностью осознаю то, что в предложенном выше “черновом наброске сильнобюджетного решения осуществимого только в случае наличия на предприятии _очень_ грамотного админа” есть прорехи. Но они решаемы. Можно добавить в комплекс одну p505 которая будет всё это хозяйство мониторить, и перекраивать LPAR. Но решаемо. За Деньги. Или за идею. Скорее за первое.
    Что же касается одной DS8300, да и всего этого комплекса. Планирование + планирование + планирование + тестирование + тестирование + тестирование. Причем во время тестирования желательно почувствовать себя “маркизом Де`Садом” и так изнасиловать эту систему, что бы любая “внештатная” ситуация казалась “до боли знакомой” и “родной”.
    Как вы, sever, правильно отметили не стоит лОжить 🙂 (“на то, на что в Питере кладут, в Москве лОжут” – слышал я такую поговорку) все яйца в одну корзину – это правильно. Наверное уже завтра, ибо сейчас хочется спать, я напишу о том каким может быть правильное решение.
    Спасибо за внимание.

    ---As If, But Not---

  • #2111

    andrewk
    Участник

    sever, дело, как уже сказал Kirill, в планировании ресурсов заранее. Если есть ресурсоемкая задача – не стоит ее виртуализировать. imho LPAR на 16 процессоров – это перебор, лучше купить отдельную машину. Но если у Вас, как например у меня, регулярно рождается огромное количество проектов, каждому из которых для работы требуется 1-2 CPU, то без использования виртуализации не обойтись. Покупать на каждый такой проект по 505й или 520й машине может показаться не сильно дороже, чем купить одну 570ю и порезать ее на LPAR’ы, но в итоге в обслуживании это вызывает больше проблем, чем одна (две в случае с DR) 570е, полностью виртуализованные. Не хочу повторять рекламные слоганы от IBM, но, поверьте, в них есть доля истины и в моей конкретной ситуации они работают.
    Ваша задача тоже решается, если заранее проводилось планирование с учетом DR, а потом это все тестировалось. Я не вижу никаких проблем с переключением LPAR’ов с одной машины на другую – регулярно этим занимаемся.

    ЗЫ. И ни в коем случае нельзя все яйца лОжить в одну корзину.

  • #2119

    warlock
    Участник

    KIRill писал(а):

    Так, давайте по пунктам. Для начала представим что есть некий заказчик купивший одну p595 (без CoD процессоров и памяти) и один DS8300 (то что за продажу такого “решения” надо увольнять без права заниматься IT в течении 10 лет промолчим).

    вообще, я бы воздержался от резких выражений в адрес заказчиков, какие бы они не были. интернет тесен, и развиртуализироваться очень легко, а люди бывают злопамятны. хотя бывает всякое, да. я вот видел в ИВЦ ГИБДД 16-головую 570, не то что без CoD, а без LPAR вообще, потому что на APV сэкономили. с другой стороны, бывают разные планы. например, мне ничего не мешает активированные процессоры поставить в резервный пул. по той причине, что покупка активации CoD (как и любого апгрейда) у IBM вызывает стойкие ассоциации с торговлей наркотиками. первая доза бесплатно, а потом чем дальше, тем дороже. при начальной закупке IBM BP достаточно легко может получить -60% от List Price. при апгрейде – даже -35% уже большая проблема. внедрение SAP – endless quest, потребление ресурсов непрерывно растет, и под этот рост, потрясая выгрузкой из OV Perfomance Manager, можно обосновать резервную машину.

    а ежели случится Большой Глюк – это будет еще одним аргументом в пользу приобретения дополнительной машины. мне дали денег на второй ЦОД только после того, как в результате глюка средней величины двое суток не работал управленческий документооборот. кстати, в моей 10-летней практике, как со стороны сервиса, так со стороны бизнеса, не было случаев, чтобы машина класса 7017-S80/p690/590/595 вышла из строя целиком. хотя через мои руки прошло немалое их количество.

    добавить в комплекс одну p505 которая будет всё это хозяйство мониторить, и перекраивать LPAR. Но решаемо. За Деньги. Или за идею. Скорее за первое.

    мы прекрасно мониторим и “перекраиваем LPAR” с HMC.

  • #2120

    warlock
    Участник

    sever писал(а):

    Если это не противоречит “политике партии” , то просьба дать такую инфу…
    Какие ресурсы (процессоры, память оперативная и дисковая) у уважаемых юзеров портала в самой большой партиции? Какая загрузка процессоров на ней в пиковое время?

    Мне это нужно для сравненительной характеристики работы сред p и i.

    Заранее благодарю.

    самая большая партиция – 20 CPU POWER5 2,2Ghz, 92Gb RAM, 1,5Tb дисков, отданных с 2107-922 (диски нарублены на LUN-ы под database layout, LUN-ы оптимизированы под разные виды нагрузки оракловых табличек, где-то под OLTP, где-то под последовательное чтение большими кусками).

    средняя загрузка (это 24×7) порядка 62-65 процентов, в пике (когда квартальные/годовой отчеты) бывает и под 100. живет там SAP R/3 Enenerprise 4.7c с большим количеством модулей. на борту порядка 5000-6000 конкурентных пользователей (это живых пользователей, не считая автоматизированные устройства учета, которые кладут данные напрямую в SAP, имя им легион). БД – Oracle 9.

  • #2121

    _KIRill
    Хранитель

    warlock писал(а):

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

    Уважаемый warlock. Вы немного не так прочитали моё послание. Я писал о том, то такое желательно не _продавать_. Ибо в случае возникновения проблем, крайним, скорее всего окажется вендор. Конечно же ситуации бывают разными. Но, если помните, изначально разговор шел о консолидации как таковой и о потенциальных проблемах при её использовании. А отнюдь не о конкретных решениях. И уж тем более не о заказчиках.

    ---As If, But Not---

  • #2122

    _KIRill
    Хранитель

    warlock писал(а):

    что покупка активации CoD (как и любого апгрейда) у IBM вызывает стойкие ассоциации с торговлей наркотиками. первая доза бесплатно, а потом чем дальше, тем дороже. при начальной закупке IBM BP достаточно легко может получить -60% от List Price. при апгрейде – даже -35% уже большая проблема.

    Ассоциация не совсем правильная, IMHO. В ценообразовании есть очень много ньюансов, о которых, как я думаю, не имеет смысла здесь говорить.

    мы прекрасно мониторим и “перекраиваем LPAR” с HMC.

    Отлично! Вот и ещё один пример того как можно разрулить ситуацию.

    ---As If, But Not---

  • #2123

    _KIRill
    Хранитель

    warlock писал(а):

    а ежели случится Большой Глюк – это будет еще одним аргументом в пользу приобретения дополнительной машины. мне дали денег на второй ЦОД только после того, как в результате глюка средней величины двое суток не работал управленческий документооборот. кстати, в моей 10-летней практике, как со стороны сервиса, так со стороны бизнеса, не было случаев, чтобы машина класса 7017-S80/p690/590/595 вышла из строя целиком. хотя через мои руки прошло немалое их количество.

    Что касается такого весомого Аргумента. К сожалению, иногда, всё именно так и происходит.
    По поводу выхода из строя машины целиком. Накопленная мною статистика полностью совпадает с вашей. Но, всё-таки, второй сайт (ЦОД) никогда не помешает.

    ---As If, But Not---

  • #2124

    Илья
    Хранитель

    warlock писал(а):

    вообще, я бы воздержался от резких выражений в адрес заказчиков, какие бы они не были. интернет тесен, и развиртуализироваться очень легко, а люди бывают злопамятны. хотя бывает всякое, да. я вот видел в ИВЦ ГИБДД 16-головую 570, не то что без CoD, а без LPAR вообще, потому что на APV сэкономили.

    🙂 Экономия должна быть экономной. Экономия на IT и экономия с помощью IT – это две разные вещи.
    PS: Я что-то не увидел “наезда” на заказчиков. А с тем что желательно продавать комплексное и высоконадёжное решение – в этом я с KIRill согласен. Конечно же все очень сильно от бюджета зависит. Главное что бы экономия не оказалась “разрушительной”.
    А вообще ведь мы о консолидации говорим?

  • #2125

    Sever
    Участник

    Вопрос про большие партиции возник по той причине, что по моей информации большинство пользователей больших систем в основном используют их для консолидации множества партиций в одной системе. Всем большое спасибо за отклики. Как я понял, большие партиции – это редкость.

    Мы работаем на операционной системе OS400(i5/OS, IBM i). AIX у нас только на Свифте, можно сказать, что он не используется вовсе. На IBMовском железе живет core system банка.
    Основные исходные постулаты для системы – максимально возможная доступность и отказоустойчивость + максимально возможная производительность в пике. Любой неплановый останов это почти катастрофа. Если не доступен сервис центральной системы, то мгновенно останавливаются все прочие сервисы, которые используют данные этой системы.
    Производительность обеспечивается максимально быстрыми процессорами и их числом, большим объемом оперативной памяти и по возможности максимально большим числом дисков в зеркале на уровне RIO петель. Дисковая система должна обеспечивать поддержку максимальной интенсивности ввода вывода. Операционная система распределяет данные по дискам и балансирует нагрузку самостоятельно.
    Большинство задач переработано для работы в многопоточном режиме. В системе работает более 3 тысяч интерактивных пользователей, масса задач пакетной обработки, масса задач репликации на другие системы, более тысячи задач поддержки принтеров. Все задачи структурированы по классам и приоритетам. Система способна работать на 100% загрузке процессоров без какого либо паразитного влияния на время отклика для высокоприоритетных задач.

    Система постоянно увеличивается по мощности для обеспечения растущей нагрузки, причем, любые апгрейды операционной системы или оборудования проводятся безболезненно для данных и доступности сервисов – на время таких работ производится переключение на аналогичный резервный сервер со своими процессорными и дисковыми ресурсами. Репликация всех изменений на резерв идет в онлайне, что обеспечивает максимальную защиту от возможных сбоев на основном сайте.
    Итоговые характеристики системы в настоящий момент – 24 процессора 5Ггц + 384Гб оперативной памяти + 20Тб дисковое пространство (40Тб в зеркале). Резервный сервер чуть слабее по числу процессоров, но в любой момент готов подхватить нагрузку. Дисковая система на резерве своя. По сути это небольшой территориально разнесенный суперкомпьютерный кластер.

    Теперь на тему консолидации на уровне многих партиций внутри одной системы. Такой задачи никогда ранее не стояло. Есть системы с несколькими партициями, – так исторически сложилось. Сопровождать их очень трудно.
    Простые примеры:
    – апгрейдил 570ю с четырьмя партициями на новую power6 9117-MMA. Восстановление конфигурации партиций (о чем декларировала IBM) не работает. Пришлось руками в цейтноте пересоздавать на консоли конфигурации заново по имеющемуся старому плану. Ошибся картами – взаимно перепутал назначение карт и пришлось партиции перегружать для переназначения ресурсов, а на это надо массу времени. При апгрейде 595ой с одной партицией на 9119-FHA достаточно было просто назначить все ресурсы сервера в партицию и указать загрузочный ресурс – ошибиться невозможно.
    – теперь вылезла проблема невозможности получить план системы на 320ой прошивке при подключенном к серверу иксовом адаптере – нужно прошивку ставить 340ю. Для проведения работ надо гасить все партиции, а среди них есть одна, которую бизнес не согласовывает выключать. Вот и работает система без плана, а без него в случае сбоя будет невозможно будет разобраться где чьи ресурсы.
    Вывод – много партиций накладывает дополнительные ограничения на штатный сервис и создает повышенные риски при обслуживании.

    По поводу планирования. Согласен – планирование просто необходимо. Но нельзя строить планы более чем на год. Сегодня бизнесу надо одно, завтра потребуется другое. Нельзя все предусмотреть, особенно при постоянно растущих объемах данных и меняющейся экономической ситуации.

    В любом случае тема консолидации ресурсов мне интересна – есть желание на зипе, коего в достатке, “собрать” неплохой сервер и заняться нарезкой AIXовых партиций в смеси с имеющимися партициями на “старых” системах с OS400. Тема перспективная под неё можно замутить интересные проекты, да и с AIXом можно будет попрактиковаться, а то ощущаю себя белой вороной на этом форуме 😉

    Всем участникам обсуждения спасибо.

  • #2127

    Oldnick
    Участник

    Я хотел бы немного уточнить, так как вижу некоторые недопонимания.
    Sever использует в основном i5/OS решения, а большинство участников форума AIX,
    поэтому у них разные понимания мотивации, выгод и удобств администрирования от консолидации многих патиций в рамках одной большой Power5 или 6.

    мне показалось, что дело обстоит именно так.
    действительно, в случае AIX массовая консолидации выглядит более убедительной.

  • #2140

    Дмитрий
    Участник

    Уважаемый sever, если бы Вы могли немножко просветить наше сообщество на тему “AS/400”, это было бы просто замечательно. Потому что очень многие про эту замечательную систему знают только понаслышке.

  • #2142

    Sever
    Участник

    Хорошо.
    AS/400 это название платформы, которая не похожа ни на какую другую.
    Основные её достоинства:
    1. Объектно-ориентированная архитектура.
    2. Одноуровневая память.
    3. Независимость исполняемого кода от процессорной архитектуры и системы ввода/вывода
    4. Очень сильная система защиты, которую нельзя обмануть на прикладном уровне.
    5. Встроенная в операционную систему поддержка реляционной DB2.
    6. Богатый инструментарий программирования.
    7. Самодокументированность и прозрачность среды (хелпЫ, протоколирование работы прикладных и системных задач)
    8. Высокая надежность и устойчивость от сбоев.

    Недостатки:
    1. Основной “недостаток” был порожден достоинствами. Очень устойчивая и надежная система не требует постоянных апгрейдов и особых навыков системного сопровождения. Такая система работает годами без потребности чего либо менять. Это привело к моральному застою архитектуры приложений в прикладной области и отсутствию потребности заплатить определенную сумму в твердой валюте производителю железа и ПО. IMHO это в кУпе с высокими ценами и дурацким маркетингом и послужило причиной падения рынка этой платформы в секторах среднего и малого бизнеса и закрытием отдельной линейки серверов под эту платформу.

    В настоящее время операционная система после ..дцатого переименования называется IBM i. Работает на всех имеющихся старых моделях 9406 и на POWERах. Будет работать на всех последующих поколениях систем, кои пока только в проекте…
    У приверженцев этой платформе есть своё “лобби” – об этом можно почитать тут

    Если у уважаемых модераторов и пользователей портала будут конкретные вопросы по AS/400, то постараюсь на них ответить. Если не смогу найти ответов, то,надеюсь, они найдутся у oldnickа

    Немного почитать про платформу можно тут http://www-03.ibm.com/systems/ru/i/library/

  • #2160

    Дмитрий
    Участник

    Спасибо!

Для ответа в этой теме необходимо авторизоваться.