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

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

Просмотр 18 веток ответов
  • Автор
    Сообщения
    • #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. Будет интересно выслушать мнение уважаемых людей

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