Capacity on Demand

Наращивание ресурсов по требованию

Организации, работающие в разных индустриях, имеют долгосрочный план роста, но при этом у них случаются кратковременные пиковые нагрузки на информационные системы. С опциями Capacity on Demand (CoD), доступными на системах eServer $$\text{\texttrademark}$$ p5, клиенты могут быстро реагировать как на планируемый рост нагрузки, включая дополнительные процессоры и модули памяти на постоянной основе, так и на краткосрочные пики, подключая ресурсы время. Ресурсы будут доступны сразу, без перезагрузки системы и без лишнего времени ожидания физической доставки процессоров и модулей памяти.

Основные термины (POWER4/POWER5)

Permanent Capacity Upgrade on Demand (CUoD)

Программа Capacity Upgrade on Demand (CUoD) позволяет компаниям приобрести и активизировать дополнительные процессоры или память на постоянной основе тогда, когда их реально потребуют приложения. Эта опция помогает быстрому внедрению новых приложений и увеличению производительности, например, при консолидации систем. За счет использования динамических логических разделов, нет необходимости перезагружать сервер, что устраняет время простоя.

Reserve Capacity on Demand

Опция Reserve CoD, предназначенная для обработки непредсказуемых пиковых нагрузок, позволяет активизировать процессоры в ответ на кратковременные повышенные требования к производительности системы, например, рекламные акции, пиковые нагрузки Web-сервер, и т.д. Дополнительные процессоры помещаются в общий процессорный пул и будут автоматически использованы разделами (после введения с HMC ключа активизации) для предоставления им дополнительной вычислительной мощности без вмешательства администратора системы. Пока общие требования к производительности меньше, чем количество постоянных процессоров в общем пуле, резервные процессоры не используются. При пиковых нагрузках, когда требования к процессорной мощности становятся больше, дополнительная мощность будет доступна разделам автоматически, и из предоплаченного времени будут вычитаться процессоро-дни.

Reserve CoD - пример

Это пример работы Reserve CoD. Предположим, что у клиента есть 16-процессорный сервер с 8 активными процессорами и 8 неактивными (CoD). Изначально в общем пуле процессоров нет. Все 8 активных процессора выделены конкретным разделам.

Администратор убирает 2 процессора из разделов B и C. Они автоматически помещаются в общий процессорный пул. После этого администратор стартует 2 раздела в общем процессорном пуле. Каждому разделу (SA и SB) назначается по 0.5 процессора из пула. Каждому разделу назначается по 2 виртуальных процессора. Это обозначает, что разгузка разделов будет распределена по обоим процессорам в общем пуле.

Администратор вводит ключ активизации Reserve CoD и 8 процессоров CoD помещаются в общий пул. Теперь появляется запас на 30 процессорных дней, а в общем пуле находится 10 процессоров.

Разделы "SA" и "SB" в пуле – неограничены в росте (uncapped), с параметрами VP=2 and PrU=0.5. Раздел "SC" стартует в пуле с VP = 10 и PrU = 1, в результате он может работать на всех 10 процессорах в пуле, при этом его емкость – всего 1 процессор. Сейчас задачи трех разделов распределяются по 10 процессорам в пуле. Разделы получают от этого выигрыш, при этом, пока реальная загрузка не превышает 2 PrU (количества постоянных процессоров в пуле), процессорное время не расходуется.

Когда загрузка возрастает так, что она превышает 2 PrU, автоматически используется дополнительная процессорная мощность, и процессоро-дни вычитаются из активации Reserve CoD. Даже, если ресурс нужен на 1 минуту, вычитается целый процессоро-день. Через 24 часа, если ресурсы больше не нужны, они остаются в резерве и процессоро-дни больше не вычитаются.

Теперь загрузка в разделах SA и SC выросла. Новые задачи привели к увеличению требований к процессорным ресурсам на 4 единицы. Повышенные потребности автоматически удовлетворяются путем выделения большей процессорной емкости разделам SA и SC, и 4 процессоро-дня Reserve CoD вычитаются за 24-х часовой период. Т.к. пиковая загрузка продолжается еще 12 часов, дополнительные 4 процессоро-дня вычитаются из активации Reserve CoD за следующий 24-х часовой период. Таким образом, всего расходуется 8 процессоро-дней. Т.к. общая загрузка разделов снижается в пределы 2 PrU до следующего 24-х часового периода, больше процессоро-дни не расходуются. К окончанию этого пика, остается 21 процессоро-день.

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

Когда количество процессоро-дней в Reserve CoD Activation Allocation становится меньше, чем количество процессоров в общем пуле (8), система начинает убирать процессоры из пула. Когда это происходит, посылается сообщение на HMC для уведомления администратора.

Когда администратор принимает сообщение о том, что процессоры удаляются из общего пула и помещаются обратно в резерв, он может выбрать следующее:

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

On/Off Capacity on Demand

Программа On/Off CoD дает организации возможность обрабатывать планируемые временные пиковые нагрузки. Работая, как кредитная карта с выставлением счета за квартал, она позволяет временно активизировать процессоры или память. Когда администратор вводит ключ, неактивные процессоры могут быть назначены конкретным разделам или добавлены в общий процессорный пул. Если они попадают в общий пул, загрузка всех общий разделов диспетчеризируется на все процессоры в пуле.

Когда требования возрастают выше, чем количество постоянных процессоров в пуле, к клиентскому счету приплюсовываются процессоро-дни и дни использования памяти. Отсчет ведется с момента активизирования процессоров и памяти и до момента деактивизирования, в целых днях. Срок действия ключа (enablement key) истекает через 360 процессорных дней. Ресурсы больше не могут быть активированы, пока не будет получен новый ключ (с сайта IBM). Ежемесячный отчет требуется даже в том случае, если процессоры не были использованы. Если отчет не высылается, клиенту выставляется счет за 90 процессорных дней. On/Off CoD может быть отключена путем обращения к IBM и вводом ключа отмены (termination key). Тогда отчет больше не требуется.

On/Off CoD – выделенные разделы - пример

On/Off CoD предоставляет гибкий механизм для активизации CoD процессоров и памяти для обслуживания запланированных пиков. В этом примере мы посмотрим, что происходит, когда CoD процессоры и память активизируются и выделяются в конкретные разделы. В примере, на сервере установлено 12 активных процессоров и 4 CoD процессора. Администратор стартовал 5 разделов, разделы "A", "B" и "C" – выделенные, а разделы "SA" и "SB" работают в общем пуле.

Администратор знает о том, что приближается пиковая нагрузка на систему (например, квартальный отчет или рекламная акция), и ему нужно 2 дополнительных процессора и 8 ГБ оперативной памяти в разделе "B" на одну неделю. Он приобретает активацию On/Off CoD. Ключ получается бесплатно. С момента его ввода и активизации процессоров и памяти система ведет мониторинг использованных ресурсов и генерирует отчеты.

В этом примере, администратор активизирует On/Off CoD и выделяет 2 дополнительных процессора и 8 ГБ оперативной памяти в раздел "B".

Когда загрузка возрастает, предоставляются дополнительные ресурсы. Пока активна On/Off CoD, ресурсы доступны для использования в разделе "B". Они будут использованы при необходимости автоматически, при этом информация об использовании процессоро- дней и дней работы памяти будет сохранена. В нашем примере, ресурсы были выделены на 7 дней – истрачено 14 процессоро-дней и дней работы памяти. Администратор самостоятельно может отключить On/Off CoD – при этом ресурсы деактивизируются и дополнительная оплата не производится.

On/Off CoD – выделенные разделы и общий пул - пример

В этом примере администратор стартовал 8 активных процессора в выделенных разделах "A", "B" и 4 активных процессора в общем пуле. Он знает, что будет пиковая загрузка, которая потребует 4 дополнительных процессора на 5 дней.

Администратор активизирует все 4 CoD процессора, 2 выделены в раздел "B" и 2 – в общий пул.

Все 4 активизированных процессора доступны для использования, процессоро-дни начнут начисляться за каждый 24-х часовой период до момента деактивизации их администратором.Даже если процессорные ресурсы не используются (например, используется только 14 processor units – 10 в выделенных разделах и 2 в общем пуле), процессоро-дни все-равно начисляются за все активизированные CoD процессоры.

Когда администратор отключает 4 CoD процессора, их использование прекращается и клиенту начисляется 20 Processor Days.