PowerVM+HACMP: Оптимальное распределение ресурсов процессора


Главная Форумы POWER Systems Виртуализация POWER PowerVM+HACMP: Оптимальное распределение ресурсов процессора

В этой теме 18 ответов, 5 участников, последнее обновление  roman 8 года/лет, 1 месяц назад.

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

    roman
    Участник

    Есть 2 p520 с нарезаными LPARами. На одной p520 один LPAR крутит прикладуху, на второй — standby LPAR, а также другие вспомогательные LPARы. Все разделы — capped. Почти все ресурсы второй машины принадлежат standby LPARу, и, соответсвенно, они простаивают. Хотелось бы отдать побольше ресурсов вспомогательным LPARам в момент, когда standby LPAR не нужен, и чтобы они отдали эти ресурсы в момент failover кластера. Возможен ли такой вариант? С теорией знаком, но не хватает практики, поэтому хотелось бы услышать конкретные предложения, в частности, что касается ресурсов процессора.

  • #5511

    Sever
    Участник

    Вам подойдет простой вариант — все партиции на второй машине объявляются uncapped, балансировка производится через два параметра вес партиции и число виртуальных процессоров.
    Для низкоприоритетных партиций вес объявляется низким, число вирт.процессоров = 1
    Для «основной» партиции вес выставляется в 255, число вирт.процессоров = числу активных физических процессоров (ядер).

    С такими настройками низкоприоритетным партициям будут доступны максимум ресурсов, пока «основная» не захочет поработать.
    При желании последней партиции потрудиться, ей будут доступны большие ресурсы проц.мощности в соответствии с её весом относительно остальных.

  • #5514

    roman
    Участник

    Спасибо за ответ. Но хотелось бы еще немного уточнить. Рассмотрим более конкретно. У нас p520 с 4 процессорами. На этом сервере есть standby-партиция и 2 низкоприоритетных партиции (не берем в рассмотрение vios). При простое standby-партиции она должна потреблять как можно меньше ресурсов, в активном режиме — например, 3 процессора. Насколько я понимаю, при такой конфигурации низкоприоритетных партиций они не получат больше чем, 1 физический процессор. Остальные ресурсы будут простаивать?

  • #5516

    sdudnik
    Участник

    Не будут они простаивать. Если партиции с большим весом в данный момент не нужны процессоры. Эти процы будут работать на две остальный партиции. При файловере все процы будут отданы стэнд-бай партиции. И не стоит забывать про виос. Если у него будет мало ресурсов, это отразиться на работе стэндбай партиции. Тут есть 2 варианта — или сделать его capped и назначить ему ресурсов, или сделать uncapped и назначить вес равный весы stanby партиции ( и назначить 1 вирт процессор)

  • #5519

    roman
    Участник

    Можно тогда прокомментировать формулу выделения процессорных ресурсов из известного редбука sg247940 — PowerVM Virtualization on IBM System p Introduction and Configuration Fourth Edition (стр.38). Если я правильно ее понял, то в распределении процессорных ресурсов участвуют все работающие uncapped-партиции

  • #5520

    roman
    Участник

    И еще один вопрос. Если я назначу 1 вирт.процессор низкоприоритетным партициям, то они же не получат больше 1 физического процессора. Или я снова что-то не так понял. Проблема в том, что система действующая, и нет возможности проводить многочисленные эксперименты. Поэтому и хочу получить советы людей, которые имели возможность поэкспериментировать

  • #5521

    roman
    Участник

    Еще раз внимательно перечитал распределение ресурсов процессоров в редбуке. Похоже, что в формуле рассматриваются не все uncapped-партиции, а только uncapped-партиции, нуждающиеся в дополнительных ресурсах

  • #5527

    Sever
    Участник

    roman писал(а):

    И еще один вопрос. Если я назначу 1 вирт.процессор низкоприоритетным партициям, то они же не получат больше 1 физического процессора. Или я снова что-то не так понял.

    Совершенно верно. Вы изначально сказали, что машины 520ые, а это обычно двухпроцессорные системы. Соответственно и предагалось дать по одному процессору на «доп.партиции». Если процессоров 4, а «доп.партиций» две, то число вирт.процессоров можно увеличить.

  • #5528

    Oldnick
    Участник

    виртуальные процессоры, (Processor Units) как я понимаю, нужны в основном для лицензирования операционной системы и софта.

  • #5529

    Sever
    Участник

    Вот макетка с параметрами…

    Capacity (min,desired,max):

    VIOS 0.2,0.4,2.0
    PART1 0.2,0.2,3.0
    PART2 0.2,0.2,3.0
    STANDBY 0.1,0.3,4.0

    Virt CPU (min,desired,max):

    VIOS 1,1,2
    PART1 1,2,3
    PART2 1,2,3
    STANDBY 1,3,4

    Вес партиций:

    VIOS 255
    PART1 25
    PART2 25
    STANDBY 255

    PS. Все партиции uncapped, все процессоры в режиме SHARED.

    Каждая из part1 и part2 в отдельности сможет в пике получать 50% мощности сервера целиком.
    StandBy может получить при необходимости 75% мощности сервера.
    Дополнительно сохраняется возможность тюнить вручную.

  • #5532

    Sever
    Участник

    oldnick1971 писал(а):

    виртуальные процессоры, (Processor Units) как я понимаю, нужны в основном для лицензирования операционной системы и софта.

    Нет. Число виртуальных процессоров, это то количество абстрактных процессоров, которое «видит» партиция. В реальности в каждый момент времени на физический процессор может быть смаппирован только один виртуальный процессор любой партиции. Идеальный вариант это когда сумма виртуальных процессоров всех партций не превышает числа активных физических, но иногда приходится на это правило забить для организации сред обработки похожих на данную задачу инициатора топика.

  • #5535

    roman
    Участник

    Спасибо за помощь. Но вот с последним вашим высказыванием можно поспорить. «Идеалов» быть не может. Всегда надо исходить из того, какие задачи выполняются. Например, среда, где много потоков, каждый из которых потребляет незначительное количество ресурсов. Иметь мощные процессоры в таком случае не имеет смысла

  • #5537

    Sever
    Участник

    У схемы недостаток следующий — число вирт.процессоров суммарно 8, а физических 4. В любой момент времени будут обрабатываться только 4 потока из 8ми. 4 потока будут всегда «зафолжены» + сервер будет больше тратить сил на диспетчеризацию потоков — в этом и есть неидеальность.

  • #5538

    roman
    Участник

    на каком уровне сейчас идет обсуждение: на уровне операционной системы (LPAR) или на уровне диспетчера Hypervisor?
    Еще один вопрос, который меня интересует. Нет ли каких-то нюансов с тем, что один LPAR в кластере будет uncapped, а другой LPAR — capped?

  • #5539

    Sever
    Участник

    roman писал(а):

    на каком уровне сейчас идет обсуждение: на уровне операционной системы (LPAR) или на уровне диспетчера Hypervisor?

    на уровне гипервизора.

    Еще один вопрос, который меня интересует. Нет ли каких-то нюансов с тем, что один LPAR в кластере будет uncapped, а другой LPAR — capped?

    думаю, что нет.

  • #5540

    roman
    Участник

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

  • #5544

    Sever
    Участник

    Обзор на эту тему в IBM Systems magazine

    + тут

  • #5588

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

    roman писал(а):

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

    Если реальных процов четыре, то с чего это им простаивать?
    К тому-же в системе несколько лпаров, и у каждого — свои виртуальные процы, а реальных — всего четыре.

    Кстати, насчёт веса vios-а — я бы ему, может, даже больше, чем рабочему лпару дал.

    По режиму capped/uncapped — может возникнуть сложность с количеством лицензий на софт.
    Между процим, если сделать:
    STB_LPAR = capped
    test_LPAR = uncapped,
    то ничего страшного не произойдёт.
    Если STB не хочет потреблять процессорные ресурсы, то их заберёт test (если они ему нужны в допонение к заявленной capacity entitlement, CE). Но как только они понадобятся STB (в рамках его CE), они безусловно ему вернутся, практически моментально.
    Кол-во виртуальных процов (VP) — фактор, влияющий на производительность.
    Надо учитыать, чтo
    VP min = ]CE[ (если я правильно написал, я имею в виду — СЕ, округлённое до целого в бОльшую сторону)
    VP max = СЕ*10, но не более 64.
    При этом, например:
    4-процессорная система.
    LPAR — 1 штука. СЕ=0.1. Сколько ему можно дать VP? Правильно, 1.
    Capped. Запускаем.
    Запускаем на нём while true do done
    он съедает 0.1 cpu. CPU util=100%
    меняем на Uncapped, weight=255
    съёдает 1 проц. util=1000%
    А сожрать ещё? Запускаем два скрипта while true do done — и что? Они все работают на одном проце, хотя ещё 3 (да хоть 63) свободно.
    Почему? Да потому, что когда гипервизор видит свободный визический процессор, он пытается забросить на него чеё-нибудь виртуальный процессор, а единственный виртуальный процессор нашего лпара уже работает.

    И ещё замечание: Вы не написали, p520 — P5 или P6.
    В P6 появилась опция «shared/dedicated capacity» — это значит, что лпару процы выданы в dedicated режиме, но если он их не использует, то они отдаются в качестве довеска uncapped разделам из shared pool. Но у dedicated lpar остаётся безусловнеёший приоритет на их использование. (Вроде, в настройках процов это называется allow sharing when active).

  • #5598

    roman
    Участник

    p520 на POWER6

    Про опцию «shared/dedicated capacity» просматривал документацию. Но изначально при поставке оборудования все процы были отданы в default shared pool, поэтому исходили из этого. Да и распоряжаться в случае dedicated-режима придется «целыми» физическими процами, а не в PU (особенно актуально, когда процов мало). Если я в чем-то ошибаюсь и есть какая-то реальная польза в случае dedicated-режима (именно в нашем случае), поправьте.

    Теперь по поводу соотношения виртуальных и физических процов. Если на lparе крутится, например, 8 процессов, каждый из которых потребляет незначительное количество процессорной мощности (для простоты, например, 0,5 мощности физического проца). Тогда при 8 VP гипервизор потребит все физические процы, планируя их каждые 10мс на физические процы. А при 4 VP, я так понимаю, только половину, так как на эти VP попадет только 4 процесса, о остальные 4 простаивают. Для простоты множество lparов и vios не берутся в рассмотрение. Поправьте, если я ошибаюсь. Тут, конечно, еще один интересный момент насчет диспетчеризации процессов внутри самого AIX. Будет интересно выслушать мнение уважаемых людей

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