Резервирование n 1 что это: Схемы резервирования инженерных систем ЦОД

Схемы резервирования инженерных систем ЦОД

Схемы резервирования инженерных систем ЦОД Что такое схема с N элементами в системе резервирования и как разобраться с, казалось бы, сложной таблицей Менделеева дата-центра? Прежде всего, необходимо сказать, что обозначение N происходит от английского слова «need», что в переводе обозначает «необходимость». А для ЦОД необходима его бесперебойная работа, то есть системы резервирования прежде всего отвечают за отказоустойчивость источников бесперебойного питания и систем охлаждения. Для системы резервирования этот символ N является обозначением необходимой нагрузки для эффективной работы оборудования. В одной системе, как правило, используются несколько N элементов. Их принцип работы зависит от схем, по которым они были воспроизведены. Существует несколько основных видов резервирования: N, N+1, 2N, 2N+1, 2(N+1), 3/2N. В зависимости от установленной схемы резервирования можно говорить об отказоустойчивости системы: чем система сложнее, тем она дороже и, соответственно, более устойчива к отказам и ошибкам. N. Отличительная черта такой схемы резервирования в том, что как такового резервирования в ней нет, а надежность зависит от каждого отдельного элемента N. При сбое в работе одного из них незамедлительно будет прекращена вся работа системы. Причина в том, что, когда один из элементов выходит из строя, его нагрузку перераспределить будет некуда. В результате такого сбоя данные могут быть безвозвратно утеряны, и это повлечет за собой, соответственно, материальные убытки. Эта схема уже давно не эксплуатируется как раз по причине того, что цена простоя всего ЦОД в случае неполадок слишком высока. По сути, при данной схеме зачастую отсутствует сам ИБП или генератор, а если даже они и есть, то представлены одномодульными системами. N+1 – схема с одним резервным элементом N. В системе N+1 резервный элемент остается незадействованным в работе до тех пор, пока в системе не произойдет сбой одного из основных элементов. В случае возникновения такого сбоя, резервный элемент примет на себя всю его нагрузку. Таким образом, система продолжит работать, но необходимость отключать всю систему для проведения ремонтных работ все еще возникнет. Для этого предусмотрены вариации: N+2, N+3 и т.д., в зависимости от требований уровня надежности и безопасности. Но стоит учитывать, что в этом варианте усложнение схемы может привести к большему простою. 2N – это две полные параллельные системы для каждого элемента N. То есть каждый элемент N в такой схеме дублируется, а нагрузка одинакова на двух элементах. При этом ни один из них никогда не нагружается полностью, и системы делят нагрузку 50/50, но эффективность работы при этом значительно снижается. Однако, при такой системе резервирования сбой одного или нескольких элементов N или выход из строя одной из систем не повлияют на работу всей системы в целом.     2N+1 — это параллельная система резервирования, схожая с системой 2N, но с одним дополнительным резервным элементом. Таким образом, если ЦОД выйдет из строя или потребуется техническое обслуживание, то всю нагрузку можно перенести на параллельный блок, в то время как сам дата-центр продолжит работу без остановок. Схема 2(N+1) – это параллельная система резервирования с дополнительным элементом N, в которой резервный элемент дублируется, то есть это две полные системы по схеме N+1. При возникновении сбоя или необходимости технического обслуживания резервные элементы N остаются в любом случае, резервируются и ИБП, и системы охлаждения, ДГУ ждет своего часа на отдельной площадке. Эта система считается самой отказоустойчивой. Схема 3/2N включает в себя все преимущества системы 2N, но такая система загружена на 2/3, а не на 50/50 как в системе 2N, соответственно и производительность у 3/2N будет намного выше, а счета за электричество – значительно меньше. При отказе одного из элементов минимальна вероятность потери нагрузки. Даже если выйдет из строя один из ИБП, то его нагрузку подхватит соседняя система. Как и в любой другой схеме, здесь возможны вариации: к примеру, если добавить четвертую группу ИБП, то схема уже будет называться 4/3 N. Как ни странно, данная схема пришла их сетей передачи данных и большой популярности у дата-центров не пользуется.     N Схемы резервирования N N+1 2N 2(N+1) Вероятность отказа Длительность простоя Вероятность отказа Длительность простоя Вероятность отказа Длительность простоя Вероятность отказа Длительность простоя 1 0.23% 20ч 0.0005% 0.046ч 0.0005% 0.046ч=164сек  2.7·10-9%  0.0009сек  2 0.46% 39.9ч 0.0016% 0.137ч 4.7·10-6%  1.5сек 2.4·10-5%  0.008сек  3 0.68% 59.7ч 0.0031% 0.273ч  4.0·10-8%  0.013сек  9.7·10-5%  0.03сек 4 0.90% 79.5ч 0.0052% 0.454ч 3.5·10-10%   0.0001сек  2.7·10-7%  0.08сек 5 1.13% 99.1ч 0.0077% 0.679ч 2.9·10-12%   0.000001сек  6.0·10-7%  0.20сек 6 1.35% 118.6ч 0.0108% 0.948ч  2.5·10-14%  0.8·10-8 сек  1.2·10-6%  0.37сек 7 1.58% 138.1ч 0.0144% 1.261ч  2.1·10-16%  0.7·10-10сек  2.1·10-6%  0.65сек 8 1.80% 157.5ч 0.0185% 1.618ч  1.9·10-18%  0.6·10-12сек  3.4·10-6%  1.08сек 9 2.02% 176.7ч 0.0230% 2.018ч  1.7·10-20%  0.5·10-14сек  5.3·10-6%  1.67сек 10 2.24% 195.9ч 0.0281% 2.460ч  1.4·10-22%  0.5·10-16сек  7.9·10-6%  2.49сек

принцип резервирования N+1 — это… Что такое принцип резервирования N+1?

 

принцип резервирования N+1
Системы бесперебойного электроитания (СБЭ), использующие принцип резервирования N+1, представляют собой системы с так называемым «горячим» (т. е. находящимся под нагрузкой) резервом.
[А. Воробьев. Классификация ИБП http://www.osp.ru/lan/2003/10/138056/ с изменениями]

EN

N+1 redundancy
A redundant method based on one module more than needed to fulfill the required performance. For instance, three parallel systems, each rated 2KVA, form a 2+1 redundant system for a 4KVA consumer. Failure of a single UPS will not affect systems operational performance.
[http://www.upsonnet.com/UPS-Glossary/]

Параллельные тексты EN-RU

N+X redundancy
Load remains secure in the event of a module failure.
One Ensuring a high level of availability while reducing the initial investment.
(N+1) or more (N+X) redundant modules could be added to the system
[GUTOR Electronic LLC]

Резервирование по принципу N+X
Электропитание нагрузки в случае выхода модуля из строя не прерывается.
Обеспечивается высокий уровень эксплуатационной готовности при сокращении первоначальных затрат.
В системе может быть один (резервирование по принципу N+1) или Х (резервирование по принципу N+X) резервных модулей.
[Перевод Интент]

 

 

N + 1 Redundancy ensures maximum uptime and continuous availability

Резервирование по принципу N + 1 минимизирует время простоя и обеспечивает постоянную готовность оборудования

Symmetra Power Array achieves N+1 redundancy and higher through proven power sharing technology.

Power sharing means that all of the power modules in a Power Array run in parallel and share the load evenly.

N+1 redundancy means running one extra module than will support your full load.

В ИБП семейства Symmetra Power Аггау резервирование по принципу N+1 или с более высокой избыточностью реализуется на основе проверенной практикой технологии распределения нагрузки.

Все модули электропитания работают параллельно и несут одинаковую нагрузку.

Резервирование по принципу N+1 означает, что число модулей электропитания превышает на 1 необходимое для питания защищаемых устройств при их работе на максимальную мощность.

In this way, all of the modules support one another.

Таким образом, каждый модуль подстраховывает другие модули

For example, if your computer load is 15kVA, you achieve N+1 with five 4kVA Power Modules.

Например, если максимальная потребляемая мощность компьютерной системы составляет 15 кВА, то для резервирования по принципу N+1 требуется пять модулей электропитания по 4 кВА каждый.

If a module fails or is removed, the other modules instantaneously begin supporting the full load.
It does not matter which module fails because all of the modules are always running and supporting your load.

В случае аварии или отключения одного из модулей нагрузка мгновенно перераспределяется на остальные модули.
Не имеет значения, какой именно из модулей прекратит работу — каждый одновременно выполняет функции и основного и резервного.

Теория вероятностей: резервирование и время безотказной работы ЦОД

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

Известно, что каждое оборудование имеет такие характеристики, как ресурс, время безотказной работы и средняя длительность простоя за год использования. Также заметим, что уровни надежности ЦОД (Tier), являясь одной из основных характеристик ЦОД, зависят от времени простоя за год. Это неспроста: именно от длительности простоя зависит успешность бизнеса компании и её непредвиденные убытки.

Итак, при построении ЦОД вкладывают деньги для реализации той или иной схемы резервирования с целью сократить время простоя и, следовательно, сократить и убытки от простоев. Всегда ли оправдываются эти вложения? Всё зависит от схемы резервирования. Именно по этому критерию будет разделен последующий материал.

Схема резервирования отсутствует: N

В данном случае ни одна система не  резервируется (Tier I) и  простой каждой единицы оборудования означает простой всего ЦОД. Общий простой ЦОД за год составляет 28.8ч (Коэффициент отказоустойчивости 99,671%). Эта схема была характерна для ЦОД 60-70х годов прошлого века и полностью изжила себя к настоящему моменту по причине предельной убыточности: сегодня убытки компании от пары часов простоя если и не превышают стоимость дополнительной (резервной) единицы оборудования, то как минимум равны ей.

Схема резервирования N+1

Схема резервирования N+1 наиболее распространена на сегодняшний день. Согласно ей, к N рабочим единицам добавляется одна резервная. Здесь всегда важно правильно определить значение N. Рассмотрим этот аспект, условно приняв, что штатный простой одной единицы оборудования составляет S0 часов в год (вероятность отказа равна P0=S/(24ч/дн*365дн)=S/8760).

Очевидно, если N=0, то время простоя в год S(N=0)=S0, а вероятность отказа P(N=0)=S/8760= P0.

Если N=1, то вероятность отказа соответствует случаю, когда одновременно не работают обе единицы оборудования. P(N=1)=P1=P0*P0, S(N=1)=S1=P0*P0*8760.

При N≥2 система неработоспособна, если одновременно отключилось не менее двух любых единиц оборудования. Таким образом, в случае N=2 должны отключиться (1 и 2), (2 и 3), (1 и 3) единицы оборудования (вероятность каждого события равна P1=P0*P0) при условии работоспособности третьей единицы (вероятность 1-P0) или все три (1, 2 и 3) вместе (вероятность равна P0*P0*P0). Получаем следующую вероятность отказа системы: P2=3*P0*P0*(1-P0)+P0*P0*P0.

Для N=3 имеем три случая отказа:

• вышли из строя любые две единицы оборудования (шесть вариантов с вероятностью P1=P0*P0 каждый) при условии работоспособности оставшихся двух единиц (вероятность (1-P0)*(1-P0)),
• вышли из строя  любые три единицы оборудования (четыре варианта вероятностью P0*P0*P0 каждый) при условии работоспособности оставшейся единицы (вероятность 1-P0),
• вышли из строя все четыре единицы оборудования (вероятность P0*P0*P0*P0).(N-1)/2; S(N)=P(N)*8760.

  Рассмотрим применение полученных формул на примере.

  Пример №1. Штатный простой оборудования в год составляет 100 часов. Каков будет простой оборудования без резервирования и при схеме резервирования N+1 с различными N?В данном случае S0=100, P0=100/8760=0.0114=1.14%. Используя формулу для P(N) заполняем таблицу 1:

  Конфигурация	Вероятность отказа, %	Время простоя за год, ч
  1	1.14%	100
  1+1	0.0130%	1.14
  2+1	0.0335%	2.93
  3+1	0.0764%	6.69
  4+1	0.1260%	11.03
  5+1	0.1867%	16.35

  Вывод: Вероятность отказа и время простоя на порядок ниже при использовании схемы резервирования N+1, чем при отсутствии резерва вовсе. Однако, вероятность отказа и время простоя растет с ростом N, т.е. с ростом общего числа элементов в системе. Тем самым выполняется принцип “чем сложнее система, тем она менее надежна”. Интересно, что в этом примере вероятность отказа при N=14 сравняется с конфигурацией без резерва.

  Данные, приведенные в примере, характерны, например, для ИБП. Если учесть, что простой системы бесперебойного питания означает отсутствие питания как такового, а, значит, и простой всего ЦОД. По данным Berkeley Internet Week 2000 Contingency Planning Research, приблизительные потери, которые могут быть вызваны простоем продолжительностью в 1ч на предприятиях различных типов в США составляют (таблица 2):

  Тип предприятия	Стоимость часа простоя
  Биржевые транзакции	Несколько млн. долл.
  Авторизация кредитных карт (банки)	$2 000 000
  Amazon	$180 000
  Бронирование билетов на самолеты	$89 000
  Резервирование (отелей, автомобилей и т.п.)	$41 000
  Банкоматы	$14 000

  Поэтому разница между конфигурациями 1+1 и 3+1 для компании по бронированию билетов может обойтись в __________$45 000.

  Схема резервирования 2N

  Согласно схеме резервирования 2N каждый элемент системы дублируется аналогичным.

  Вероятность отказа ИБП и российские электросети

  Большинство ИТ-оборудования, устанавливаемого в ЦОД требует высокого качества питания. Именно такое электропитание призваны обеспечить источники бесперебойного питания. При расчете рисков, связанных с обесточиванием ЦОД, огромное значение имеет доступность ИБП. В интернете можно найти следующие данные по доступности ИБП при различных конфигурациях системы бесперебойного питания (таблица 3 (Журнал сетевых решений “LAN”, №10 за 2008г.)):

  Конфигурация ИБП	Доступность (с байпасом), %	MTBF
  1+1	99.99999932	2182.9
  2+1	99.99999899	1455.3
  3+1	99.99999865	1091.5
  4+1	99.99999831	873.2
  5+1	99.99999797	728.4
  6+1	99.99999763	624.3
  7+1	99.99999730	545.3
  8+1	99.99999696	485.6
  9+1	99.99999662	437.0
  10+1	99.99999628	397.3

  Как видно, доступность системы весьма велика, а время простоя для случая “1+1″ составит всего 0.2 секунды в год. Означает ли это, что Заказчик может рассчитывать на простой ЦОД в течение 200 миллисекунд в год?

  Конечно, ответ “нет”! Но он скрыт в словах “с байпасом” во второй колонке таблицы. Оказывается, что в течение 0.2с ЦОД будет просто без питания, а всё остальное время он хоть грязное питание из сети (по линии байпаса), но получит. Обратимся к первоисточнику: что нам обещают предоставить электросети?

  Согласно ГОСТ 13109-87 п.6.2, качество электрической энергии не должно выходить за рамки допустимого диапазона в течение 95% времени (438 часов в год). А длительность подачи электроэнергии пониженного качества не должна превысить 90 часов за год.

  Таким образом, порядка 90 часов в год ЦОД будет запитан низкокачественной электроэнергией, что по сути можно приравнять к его простою (если ещё не выходу из строя некоторого (наиболее чувствительного и, как правило, наиболее дорогого) серверного оборудования). Следовательно, вместо доступности 99.99999932% получаем доступность 99.99999932%*95%=94.999999354%≈95%.

  Вывод: в течение 438 часов ежегодно ЦОД будет лишен требуемого качества электропитания, а убытки компании по резервированию отелей, согласно таблице 2, составят $17.5 млн.

  Автор: Хомутский Юрий / alldc.ru

  Отказоустойчивость ИТ-инфраструктуры Tier и схемы резервирования системы БП

  Инженерная инфраструктура центра обработки данных (ЦОД) или крупного ИТ-отдела – это не только компьютерное и сетевое оборудование, но и система бесперебойного электроснабжения, которая поддерживает работу оборудования при отключении основного (внешнего) электропитания.

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

  Как строятся системы бесперебойного электроснабжения

  Чтобы получить надежную систему обеспечения бесперебойным питанием для ЦОД, используют централизованную, распределенную или комбинированную схему.

  При централизованной все потребители подключены к одному или нескольким мощным (обязательно трехфазным) ИБП. Они же выступают посредниками между потребителями и основным входом сети электропитания.

  В распределенной – комплекс независимых ИБП (преимущественно однофазных), каждый из которых защищает группу однотипных или близко расположенных потребителей.

  Серьезный недостаток централизованной системы – единая точка отказа. Если выйдет из строя один или группа основных ИБП, без электропитания останется весь дата-центр.

  У распределенной системы другие проблемы – аппаратная избыточность, низкий КДП и сложность управления и контроля.

  Лучшее из обеих схем объединила в себе комбинированная система. В ней есть и основной мощный ИБП первого уровня на входе, и независимые дополнительные источники второго уровня, которые защищают всех или наиболее ответственных потребителей.

   

  Чтобы повысить надежность дата-центра, используют резервирование, при котором отказоустойчивость растет благодаря дублированию ИБП.

  Tier как основной показатель надежности ЦОД

  Одна из главных характеристик дата-центра – его Tier или уровень надежности. Систему классификации, включающую четыре категории надежности (Tier I – IV), в 90-х годах прошлого века разработал Uptime Institute. Категория ЦОД указывает на уровень резервации инфраструктуры, ее физической безопасности и надежности. С помощью Tier легко просчитать ожидаемый уровень надежности и потенциальные инвестиции в дата-центр, его коммерческие перспективы и технологические стратегии.

  Когда говорят о надежности, подразумевают не только бесперебойную работу серверного оборудования, СХД и линий передач данных, но и вообще любых инженерных компонентов, поддерживающих работоспособность ЦОД. Это и системы охлаждения, и насосы, которые подают топливо для дизель-генераторов. От проблем с электропитанием нужно защитить каждую единицу оборудования.

  Еще одно уточнение по классификации Tier: каждый следующий уровень в ней является прогрессирующим, то есть включает все требования к предыдущему.

  Tier I – базовая категория надежности

  Дата-центры с Tier I поддерживают нагрузки, связанные с базовыми офисными задачами. В них отсутствуют дублирующие активные компоненты. Чтобы провести плановые работы (а без них не обойтись, если вы хотите предотвратить нежелательные простои), придется остановить ЦОД.

  N – минимальное число ИБП, которые гарантируют
  стабильную работу защищаемого оборудования.

  В Tier I нет аппаратной избыточности, то есть схема резервирования не используется, а количество ИБП остается минимальным (N). При таких условиях ЦОД простаивает до 28,8 часа в год. В это число входит продолжительность внеплановых отключений и обязательного планового обслуживания. Уровень отказоустойчивости такого дата-центра – 99,671 %.

  Tier II – резервные ресурсы

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

  В Tier II используется резервирование по схеме N+1 – с одним дополнительным элементом. Но чем больше число N, тем выше вероятность отказа и дольше время простоя. Очевидно, что при N=1 и схеме резервирования 1+1 простой будет наименьшим (официальная цифра – 1,14 часа в год), а при N=14 – достигнет показателей конфигурации, в которой резервирование не используется вовсе, то есть N в Tier I. Отказоустойчивость в Tier II – 99,749 %, а среднее нерабочее время – 22 часа в год.

   

  Tier III – параллельное сервисное обслуживание

  Дата-центры Tier III поддерживают техобслуживание и ремонт без остановки критически важного оборудования. Это касается не только вычислительных мощностей, но и каналов связи, систем охлаждения и т. п. Любой элемент ИТ-системы можно отремонтировать или отключить, не влияя на работу ЦОД.

  В Tier III используется схема 2N, где все компоненты продублированы. В таких случаях часто подключают к нагрузке две параллельные линии электропередач одинаковой мощности, но не меньше мощности потребляемой нагрузки. Для Tier III уровень отказоустойчивости составляет 99,982 % («три девятки»), а ежегодное время простоя не превышает 1,6 часа.

   

  Tier IV – максимальная отказоустойчивость

  Дата-центры Tier IV строятся по схеме Tier III, где принципы отказоустойчивости реализованы так, чтобы сбои в работе отдельного оборудования или резервного канала подачи электроэнергии не влияли на ЦОД.

  Четвертому уровню защиты соответствует резервирование по схеме 2(N+1), где питание нагрузки по каждой из двух линий дополнительно зарезервировано по схеме N+1, как в Tier II. Уровень отказоустойчивости, который обеспечивает схема 2(N+1), называют «четыре девятки», это 99,995 %, или простой менее 0,4 часа в год.

  Чем больше резервных единиц, тем выше уровень надежности Tier,
  сложнее ИТ-инфраструктура и больше траты на ее содержание.

  Дополнительные схемы резервирования

  Перечисленные выше схемы резервирования можно видоизменять. Например, N+1 представляет собой разновидность концепции N+X, где X – количество дополнительных резервных единиц. N+2 дает ощутимый прирост надежности в системах с небольшим количеством N, но при этом дешевле в реализации, чем 2N. Но по мере роста N разница в стоимости между N+2 и 2N уже не компенсирует прирост отказоустойчивости, который обеспечивает второй вариант, Tier III.

  Система 2N – тоже не единственный возможный вариант. Как и в предыдущем примере, можно организовать резервирование по схеме 3N и даже 4N. Другое дело, что из-за экономического фактора и сложной реализации такие системы встречаются редко.

  Высокая надежность дата-центра: прихоть или необходимость?

  Tier IV – это не только надежно, но и дорого. На самом деле, аппаратная избыточность источников бесперебойного питания нужна не каждому бизнесу. В небольшой компании, где не проходят критически важные процессы, из-за остановки которых она теряет деньги, достаточно Tier I. Правда, для ЦОД эта схема не используется последние полвека. Tier II с резервированием по схеме N+1 – тоже не лучшее решение, но оно оправданно в некоторых ситуациях.

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

  Другое дело – ИТ-служба крупной компании, которая предоставляет услуги в режиме 24/7/365, или современный ЦОД. В них даже кратковременная остановка приведет к серьезным финансовым и репутационным потерям. Такой бизнес предъявляет строгие требования к безотказной работе.

  Обычно решения, которые разрабатываются в соответствии с Tier III и Tier IV, служат даже дольше, чем того требует ИТ-инфраструктура. Это оптимальный выход для компаний, которые не рассчитывают на быстрое возвращение инвестиций в резервирование системы электроснабжения и знают, во сколько им обойдутся простои.

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

  ВЗАИМНОЕ РЕЗЕРВИРОВАНИЕ ЭЛЕКТРОСТАНЦИЙ БЕЗ ПАРАЛЛЕЛЬНОЙ РАБОТЫ

  Параллельное включение источников питания по схеме n + N является распространенным способом повышения надежности системы бесперебойного гарантированного электроснабжения. Объединение в параллельную группу n + N ИБП диктуется требованием нагрузки к бесперебойности питания. Как правило, нагрузка, защищаемая ИБП, относится к особой группе электроприемников I-ой категории, т.е. не допускает перерывов в электроснабжении. Параллельное включение ИБП позволяет организовать бесперебойность питания потребителей при выходе одного (или нескольких, не больше N) источника из строя.

  Часто такая практика несправедливо распространяется на ДГУ – Заказчик предполагает, что резервирование электростанций требует объединения ДГУ в параллельную группу. Необходимость параллельной работы электростанций очевидна, если необходимо резервировать мощный ввод, а доступные единичные мощности электростанций невелики, если предполагается электроснабжение нагрузки с изменяющимся суточным или сезонным потреблением электроэнергии. Внутри параллельной группы можно реализовать n+N резервирование – это не только обеспечит повышение надежности системы электроснабжения при отказе ДГУ, но и обеспечит гарантированное питание нагрузки в случае выведения ДГУ на периодическое ТО.

  Вместе с тем, организация параллельной работы ДГУ в системе резервирования 1+1 нам представляется нецелесообразной. В случае, если мощности одной электростанции достаточно для резервирования ввода и нагрузка не имеет заметных суточных/сезонных колебаний, 1+1 резервирование ДГУ может быть реализовано по схеме Dual Mutual Standby©, cм. Рис 1.

  Основные вводы резервируются двумя электростанциями, подключаемыми через один АВР ДГУ. При пропадании основного и резервного вводов автоматика основного АВР формирует сигнал на запуск обеих ДГУ (сухой контакт). ДГУ, назначенная Master, запускается при получении сигнала на удаленный запуск; ДГУ, назначенная Slave  – при получении сигнала на удаленный запуск И получении сигнала от Master «Alarm/Shutdown». Сигнал «Alarm/Shutdown» формирует управляющий контроллер ДГУ в случае аварии электростанции. Сигнал формируется в виде сухого контакта.

  Присвоение приоритетов Master и Slave выполняется на этапе программирования управляющих контроллеров ДГУ. Приоритеты можно изменять в зависимости от наработки двигателя – необходимость изменения и шаг, с которым меняются приоритеты, так же выбираются при программировании контроллера.

  Взаимное резервирование ДГУ было многократно реализовано на базе дизельных электростанций GESAN GRUPOS ELECTROGENOS (35-3100кВА), при этом использовался управляющий контроллер со встроенной функцией Dual Mutual Standby© — Deep Sea 7310.

  Преимущества такой схемы резервирования перед параллельной группой из двух электростанций:

   – может быть построена на стандартном оборудовании GESAN, что в свою очередь, означает более короткие сроки поставки (в том числе – отгрузку оборудования со склада) и меньшую стоимость оборудования.

  — может быть выполнена с использованием электростанции, уже установленной и работающей у Заказчика.  

   

   

   

  Последовательное резервирование (Serial Redundancy)

  
  Часть I

  Схема «Резервирование Hot-standby / Serial Redundancy»

  Большинство промышленных ИБП имеют два входа — главный (вход выпрямителя, rectifier input, main input) и резервный (вход байпаса, Bypass input).

  Все ИБП имеющие два входа могут использоваться в системе с последовательным резервированием. Примеры ИБП поддерживающих схему включения «Serial Redundancy»: Power-Vision Black THD 3/1, Power-Vision 3F, Safe-Power Evo, Power-Vision Black MP 3/3, Power-Vision HF, Power-Vision W и др.

  Схему с последовательным резервированием также называют «Serial Redundancy», «Hot-standby redundancy» или «Резервирование Hot-standby»

  Cистема «Последовательное резервирование Hot-standby» показана ниже на рис. 1.

  Цель последовательного резервирования — повышение надежности системы электроснабжения критичного оборудования путем последовательного соединения ИБП. Так же растёт время автономии по сравнению с одиночным ИБП.

  Стандартная система с последовательным резервированием состоит из одного основного (ведущего/ master) модуля ИБП и одного резервного (ведомого/slave) модуля ИБП (для нестандартных систем количество как основных так и резервных модулей больше). Основной модуль работает на нагрузку. Резервный модуль используется в качестве резервного источника питания для входа Байпас основного модуля системы.

  При пропадании питания на входе, оба ИБП переходят в автономный режим работы, нагрузка потребляет энергию батарейного комплекта основного ИБП. Если к моменту его разряда питание не восстановится, произойдет автоматический переход основного ИБП в Байпас, т. е. в итоге нагрузка будет питаться от резервного блока ИБП (нагрузка потребляет энергию батарейного комплекта резервного ИБП).

  Можно считать, что эта система является частным случаем системы с избыточным резервированием N+1(N+X) так как имеет следующую логику работы: если велинчина нагрузки не превышает нагрузочную способность N блоков ИБП, то поломка* одного любого (и более до X) ИБП не приведёт к отключению нагрузки, и оставшийся исправный ИБП (или N блоков ИБП) продолжит питать нагрузку.

  Возможность системы продолжить питание нагрузки при поломке одного из модулей (с учётом своевременного ремонта вышедшего из строя ИБП) резко повышает надёжность системы так как вероятность одновременной поломки обоих ИБП ничтожно мала.

  Отличие по логике от стандартной параллельной системы (N+1)N+X (parallel redundant) заключается в поочерёдном, а не синхронном исчерпании энергии батарей (при использовании единого батарейного кабинета этого отличия нет), а также в отсутствии распределения нагрузки между блоками ИБП. Применение данной схемы особенно эффективно для On-Line ИБП имеющих нулевое время переключения Байпас<->Инвертор, таких как Power-Vision Black 3/1(1/1). Если же используются ИБП с ненулеым временем прехода Байпас<->Инвертор, то, тот факт, что время переключения не равно нулю -является серьёзным отличием (ухудшением) по сравнению с системой с параллельным резервированием (в параллельных системах, для большинства типов OnLine ИБП, время переключения между блоками равно нулю).

   

  Рис.1 Cистема «резервирование Hot-standby»

   

  Принцип работы схемы «Резервирование Hot-standby»

  Нормальный режим работы (входная сеть в норме):

   

  Рис.2 Поток энергии при нормальном режиме работы

   

  Рис. 2 показывает нормальный поток энергии когда входная сеть в норме. Поток энергии поступает на основной ИБП и с него на нагрузку. Резервный ИБП работает в холостом режиме. Если на основном ИБП произойдёт авария, он перейдёт в байпас и нагрузка будет запитана от резервного ИБП как показано на рис.3:

   

  Рис.3 Поток энергии в аварийном режиме работы (основной ИБП неисправен)

   

  Если сеть не в норме или отсутствует, то оба ИБП перейдут в батарейный режим . Поток энергии поступает из батарей основного ИБП на нагрузку. Резервный ИБП работает в холостом режиме. Если на основном ИБП разрядются батареи или произойдёт авария, он перейдёт в байпас и нагрузка будет запитана от резервного ИБП который будет питать нагрузку до разряда батарей. Если сеть восстановится, то система переходит в нормальный режим работы.

   

   

  ---

  * это справедливо для случая если авария ведущего (основного/Master) ИБП — любая авария любого блока (инвертор, ЗУ и др.) при которой остаётся исправной линия Байпас. Для классического случая системы с избыточным резерви

  что это такое и как он работает

  Объем генерируемой человечеством информации постоянно растет. По прогнозам специалистов, к 2025 году объем всех данных в мире составит 163 зеттабайт (ЗБ). Это в 10 раз больше, чем в 2016 году.

  Для обработки и хранения информации существуют центры обработки данных (ЦОД). Они представляют собой специализированные помещения или целые здания, где устанавливается серверное и сетевое оборудование, а также выстраивается соответствующая инфраструктура. ЦОД может быть крупным, занимая одно или несколько зданий, а может быть совсем небольшим, размещаясь в отдельном помещении.

  Для чего нужен ЦОД и кто его использует?

  Центры обработки данных, или дата-центры (от англ. data center), отвечают за бесперебойную работу всего установленного внутри оборудования и соответствующей инфраструктуры. ЦОД должен выполнять такие функции, как:

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

  Используют ЦОД бизнес, правительственные и научно-исследовательские организации для самых разных нужд. Объединяет их одно: необходимость обработки и хранения огромных массивов информации.

  Уровни надежности ЦОД

  Чем важнее задача, выполняемая центром обработки данных, тем надежнее он должен быть. Пара минут простоя ЦОД может стоить бизнесу нескольких миллионов долларов. Для оценки уровня надежности ЦОД компания Uptime Institute разработала специальную систему сертификации — Tier. Уровни сертификации:

  • Tier I. Это базовый ЦОД, в котором используется система резервирования N+0 (об этом ниже). У таких объектов в большинстве случаев нет дублирующих систем. Максимальный уровень доступности ЦОД (отказоустойчивость) составляет 99,671%.
  • Tier II. Более надежный объект, в котором применяется схема резервирования N+1. Системы зарезервированы, но в случае необходимости ремонта ЦОД приходится останавливать. В дата-центрах уровня Tier 2 обязательно должен присутствовать фальшпол. Отказоустойчивость ЦОД — 99,75%.
  • Tier III. При поломке какой-либо из систем ЦОД продолжает функционировать, ремонт можно выполнять без остановки всего объекта. Отказоустойчивость ЦОД — 99,98%.
  • Tier IV. На данный момент это самый высокий уровень сертификации. У любой инженерной системы есть резерв как основного, так и дополнительного узла (схема резервирования 2N+1). Отказоустойчивость — 99,99%, время простоя сведено к минимуму. Опасности остановки такого ЦОД практически нет.

  Инженерные системы центра обработки данных

  ЦОД невозможно представить без инженерных систем, которые позволяют выполнять функции, перечисленные выше. Основных систем пять.

  Энергоснабжение. Работоспособность дата-центра зависит от бесперебойных поставок электроэнергии. Для того, чтобы обеспечить непрерывность всех процессов, инженеры ЦОД подключают объект к энергетической сети по нескольким независимым каналам, а также добавляют системы аварийного питания, включая дизельные генераторы. Они нужны на случай полного отключения всех резервных каналов.

  Кондиционирование. Перегрев оборудования чреват частичным или полным отказом. Сильнее всего в здании нагревается машинный зал, где установлена большая часть серверного оборудования. Для охлаждения обычно используют промышленные кондиционеры и/или альтернативные системы, включая фрикулинг.

  Безопасность. Как и говорилось выше, оборудование дата-центра должно быть защищено от действий посторонних лиц. Не менее важная задача — обеспечение конфиденциальности данных, которые хранятся в центре обработки данных. В большинстве случаев системы безопасности ЦОД включают систему контроля доступа, видеонаблюдение, пожарную сигнализацию, противопожарную систему и т.п. Доступ к оборудованию жестко регулируется, всегда есть охрана.

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

  Администрирование. Управлять дата-центром, всем комплексом оборудования и ПО невозможно без специальной системы мониторинга. Она дает возможность оценивать работоспособность подсистем дата-центра, устраняя возникающие проблемы на ранней стадии.

  Резервирование инженерных систем ЦОД

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

  N+0. Это базовый уровень, системы без резервирования. Если что-то ломается или отключается энергия, то останавливается работа всего дата-центра. Отметим, что в ЦОД, где требуется бесперебойная работа оборудования, необходимо многократное резервирование, так что схема N+0 здесь не подходит.

  N+1. Система резервируется однократно. Резервный элемент задействуется после того, как выходит из строя основной, так что весь комплекс продолжает работу.

  2N. У каждой основной системы или элемента есть два резерва, которые работают параллельно, так что нагрузка равномерно распределяется между всеми компонентами. Если какой-то элемент выйдет из строя, его автоматически заменяет второй.

  2N+1. Такая же схема, как и выше, но используется еще один добавочный компонент.

  2(N+1). В этой схеме дублируются даже дополнительные элементы. Одна из самых надежных схем на данный момент, которая работает безотказно.

  Дизель-генераторы ДЦ «Берзарина» Selectel

  Основные услуги дата-центров

  Главная задача ЦОД — обеспечение бесперебойной работы оборудования. А вот возможность размещения такого оборудования клиентами компании, которая владеет дата-центром, — это уже услуга. Главные услуги дата-центров:

  Все дата-центры компании Selectel соответствуют стандартам Uptime Institute уровня Tier III.

  Всего их шесть: «Берзарина» (г. Москва), «Цветочная 1», «Цветочная 2», «Дубровка 1», «Дубровка 2», «Дубровка 3» (Санкт-Петербург и Ленобласть).

  • ДЦ «Берзарина» оснащен источниками бесперебойного питания, дизель-генераторами N+1, а также системой фрикулинга с адиабатическим доохлаждением.
  • ДЦ «Цветочная 1» оснащен прецизионными кондиционерами, источниками бесперебойного питания, дизель-генераторами.
  • ДЦ «Цветочная 2» оснащен источниками бесперебойного питания, дизель генераторами с резервированием по схеме N+1, чиллерами, автоматической системой пожаротушения.
  • В ДЦ «Дубровка 1» установлены 4 дизель-генераторных установки Gesan. Они подключены по схеме 3+1, что позволяет зарезервировать полную мощность дата-центра.
  • В ДЦ «Дубровка 2» установлены источники бесперебойного питания, дизель-генераторы N+1, автоматическая система газового пожаротушения и прецизионные кондиционеры.
  • В ДЦ «Дубровка 3» используется все то же, но вместо кондиционирования применяется фрикулинг с доохлаждением.

  Определение и значение резервации | Словарь английского языка Коллинза

  Примеры «оговорки» в предложении

  бронирование

  Эти примеры были выбраны автоматически и могут содержать конфиденциальный контент.Подробнее… Прежде чем свернуть с дороги, он попал в центральную резервацию.

  The Sun (2016)

  Однако ни у кого не было никаких сомнений по этому поводу.

  The Sun (2017)

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

  Times, Sunday Times (2016)

  Нет, мои сомнения по поводу Англии носят практический характер.

  Times, Sunday Times (2016)

  Имя и адрес указаны Без оговорок Почему бы не открыть часть центральной резервации, а не просто закрыть половину автомагистрали?

  Times, Sunday Times (2016)

  Количество мест ограничено, рекомендуется раннее бронирование.

  Times, Sunday Times (2010)

  Некоторые потенциальные покупатели выразили сомнения по поводу отсутствия конфиденциальности.

  Times, Sunday Times (2007)

  Они остановились, и дочь схватила его, когда он достиг центральной резервации.

  Солнце (2014)

  Первым действием было скрытое разногласие по поводу резервирования столика в ресторане.

  Times, Sunday Times (2011)

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

  Солнце (2010)

  Подробнее …

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

  Times, Sunday Times (2012)

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

  Times, Sunday Times (2013)

  Почему вы даете мне карточку с номером телефона для бронирования, на которое никто не отвечает?

  Times, Sunday Times (2012)

  Действуют ограничения по железной дороге, подробности уточняйте при бронировании.

  Times, Sunday Times (2008)

  Моя главная оговорка по поводу книги касается ее оригинальности.

  The Times Literary Supplement (2010)

  Все бесплатно, но из-за ограниченного места необходимо предварительное бронирование.

  Times, Sunday Times (2012)

  Затем она указала на лесной массив в центральной резервации дороги.

  Times, Sunday Times (2007)

  Пропущенный столик в ресторане для нее было обычным делом.

  Христианство сегодня (2000)

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

  The Sun (2012)

  Старшие судьи по-прежнему возражают против съемок уголовных процессов и трудностей с защитой присяжных и свидетелей.

  Times, Sunday Times (2009)

  Он высказывал сомнения по поводу тренерского штаба, но многие капитаны так поступают.

  Times, Sunday Times (2009)

  Я бы попросил их написать на карточках бронирования столиков.

  The Sun (2011)

  Чтобы забронировать номер по электронной почте.

  The Sun (2014)

  Я бы безоговорочно рекомендовал его.

  Times, Sunday Times (2009)

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

  Times, Sunday Times (2008)

  Такие запросы, как бронирование номеров в отелях или ресторанах, выполняются как часть соглашения о членстве с указанием стоимости комнаты или столика сверху?

  Times, Sunday Times (2015)

  Определение бронирования, сделанное Merriam-Webster

  резервирование | \ Re-zər-vā-shən \

  а (1) : акт или факт резервации лицом, предоставившим право, какой-либо вновь созданной вещи из предоставленной вещи.

  б : установка ограничивающих условий или отказ от полной экспозиции ответил без оговорок

  c : договоренность о том, чтобы что-то (например, гостиничный номер) оставалось для личного пользования. также : обещание, гарантия или запись о таком взаимодействии

  2а : ограничивающее условие согласен, но с оговорками

  3 : что-то зарезервировано: например,

  а : Отведенный участок государственной земли (для использования американскими индейцами)

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

  бронирование | Определение, история и факты

  Заповедник , также называемый заповедником или (в Австралии) станцией , участок земли, выделенный правительством для использования одним или несколькими коренными народами.В начале 21 века резервации существовали на всех континентах, за исключением Антарктиды, но больше всего их было в Соединенных Штатах, Канаде и Австралии. Большинство резерваций в этих странах, а также во многих других, восходит к колониальной политике 19-го и начала 20-го веков. Однако некоторые резервации были созданы только во второй половине 20 века или позже.

  Долина монументов Парк племен навахо

  Всадник пасет овец в парке племен навахо «Долина монументов», часть резервации народа навахо, граница Аризоны и Юты.

  © CoolPhotography — iStock / Getty Images

  Хотя конкретные обстоятельства их образования, история и условия жизни различаются, некоторые характеристики являются относительно обычными для заповедников, созданных в XIX и начале XX веков. Например, они, как правило, создавались на основе договорных соглашений или колониального указа и неизменно представляли собой территорию, намного меньшую, а часто и находящуюся на большом расстоянии от традиционной территории данной группы. Кроме того, ранние запасы обычно размещались на экономически маргинальных землях, то есть в очень засушливых, влажных, крутых или отдаленных местах.Наконец, их формирование обычно сопровождалось принятием законов о пропусках, запрещающих местным жителям выезжать за пределы резервации. Эти и другие правила, например, запрещающие владение оружием, были разработаны для умиротворения местного населения и предотвращения образования коалиций между резервациями.

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

  Поселенцы, ожидающие официального сигнала о том, что они могут перейти на территорию индейской резервации Форт-Холл и потребовать земли племен, которые правительство США считает «излишками», Покателло, Айдахо, 1902 г. рассматриваемые вопросы почти всегда открывались рано или поздно, хотя правовые механизмы для этого варьировались от места к месту.В некоторых случаях были приняты законы, по которым определенное количество резервных земель выделялось каждому взрослому коренному населению или семье, а оставшаяся часть предоставлялась тем, кто не являлся аборигеном. Другой метод требовал, чтобы коренные жители доказали определенную степень генетического родства с первоначальными сторонами, подписавшими договор. Лица с менее чем требуемой степенью родства или количеством крови (часто, хотя и не всегда, эквивалентно наличию бабушки или прадедушки или прадедушки из группы) затем лишались права голоса на своей земле.Как и в случае с наделом, любая «лишняя» земля, предоставленная через этот механизм, впоследствии будет открыта для продажи посторонним. Эти и другие схемы значительно сократили размер большинства бронирований, в некоторых случаях более чем на 50 процентов. В сочетании с упомянутыми ранее законами о пропусках земельные уступки часто делали резервы слишком маленькими, чтобы поддерживать традиционную экономику местных жителей, занимающихся охотой и собирательством, садоводством и скотоводством. Обычно это подталкивало коренные народы к освоению колониальных форм производства продуктов питания, тем самым ускоряя темпы культурной ассимиляции.

  Получите подписку Britannica Premium и получите доступ к эксклюзивному контенту. Подпишитесь сейчас

  По сравнению с соседними незарезервированными районами, резервации исторически были слаборазвитыми с точки зрения инфраструктуры, социальных услуг, жилья и экономических возможностей. Примечательный пример из США: данные переписи показывают, что к 1950 году программами электрификации сельских районов было охвачено около 90 процентов сельских домов за пределами резервации, но такая же часть домов в резервациях не имела электроснабжения до 2000 года.Подобные десятилетия отставания в развитии обнаружены во многих заповедниках по всему миру.

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

  Условия в заповедниках, сформированных в конце 20-го и начале 21-го веков, менее однородны, чем в более старых заповедниках, в первую очередь потому, что их создание происходило при более разнообразных обстоятельствах, чем существовало в прошлом. Во многих из этих более недавних случаев, особенно в развивающихся странах, регион не определялся в качестве резерва до тех пор, пока не произошла значительная деградация окружающей среды из-за горнодобывающих, лесозаготовительных или других добывающих предприятий.В таких ситуациях активисты часто высказывали опасения, что корпорации, получающие прибыль от этих предприятий, смогут избежать затрат на восстановление окружающей среды. Напротив, многие сравнительно богатые правительства отказались создавать новые заповедники как таковые, но передали управление районами с большим количеством коренного населения региональным советам, в которых коренные народы имеют гарантированное большинство или большинство. Примеры последнего подхода включают создание в 1999 году Нунавута, канадской провинции с преимущественно инуитским населением, и изменения в 2006 году управления Финнмарком, регионом Норвегии с большим саамским населением.

  Предварительное бронирование — Платформа администрирования LSF

  Предварительное бронирование
  СОДЕРЖАНИЕ
  Что такое предварительное бронирование

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

  Только администраторы LSF или root могут создавать или удалять предварительные резервирования. Любой пользователь LSF может просматривать существующие предварительные бронирования.

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

  Активные бронирования

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

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

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

  Закрытые и открытые бронирования

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

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

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

  Запущенные задания закрыты. , повторяющееся резервирование уничтожается по истечении срока действия резервирования.

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

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

  Планирование работы с предварительным бронированием

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

  примечание:

  Если IGNORE_DEADLINE = Y, это не влияет на предварительное резервирование.Рабочие места всегда не могут быть запущены, если есть вероятность, что они столкнутся с предварительным резервированием.

  Системные бронирования

  Резервирования также могут быть созданы для обслуживания системы. Если резервирование системы активно, никакие другие задания не могут использовать зарезервированные хосты, и LSF не отправляет задания на указанные хосты, пока активно резервирование.

  Настроить предварительное бронирование
  Включить предварительное бронирование
  1. Чтобы включить предварительное резервирование в кластере, убедитесь, что плагин планирования предварительного резервирования schmod_advrsv настроен в lsb.модули .

   Begin PluginModule
  SCH_PLUGIN RB_PLUGIN SCH_DISABLE_PHASES
  schmod_default () ()
  schmod_advrsv () ()
  Конец PluginModule
   

  Разрешить пользователям создавать предварительные бронирования

  По умолчанию только администраторы LSF или root могут добавлять или удалять предварительные резервирования.Чтобы разрешить другим пользователям использовать brsvadd для создания предварительных резервирований и brsvdel для удаления предварительных резервирований, необходимо настроить пользовательские политики предварительного резервирования.

  1. Используйте раздел ResourceReservation в lsb.resources для настройки политик предварительного резервирования для пользователей.

  В разделе ResourceReservation указывается:

  • Пользователи или группы пользователей, которые могут создавать резервирования
  • Хосты, которые можно использовать для резервирования
  • Временной интервал, когда можно создать резервирование.

  Каждая политика предварительного резервирования определяется в отдельном разделе ResourceReservation, поэтому наличие нескольких разделов ResourceReservation в lsb.resources является нормальным.

  Только user1 и user2 могут делать предварительное резервирование на hostA и hostB . Временное окно бронирования — с 8:00 до 18:00. ежедневно:

   Начать резервирование ресурсов
  ИМЯ = dayPolicy
  ПОЛЬЗОВАТЕЛИ = user1 user2 # необязательно
  HOSTS = hostA hostB # необязательно
  TIME_WINDOW = 8: 00-18: 00 # еженедельное повторяющееся бронирование
  Конечное резервирование ресурсов
    
  
    user1  может добавить следующее резервирование для пользователя  user2  для использования на  hostA  каждую пятницу с 9:00 a.м. и 11:00:
   
     brsvadd -m "hostA" -n 1 -u "user2" -t "5: 9: 0-5: 11: 0"  
  Резервирование "user2 # 2" создано
    
  
  Пользователи могут удалять только те бронирования, которые они создали сами. В этом примере только пользователь  user1  может удалить резервирование;  user2  не может. Администраторы могут удалять любые бронирования, созданные пользователями.
   
    
  
  Все пользователи в группе пользователей  ugroup1 , кроме  user1 , могут делать предварительное резервирование на любом хосте в hgroup1, кроме  hostB , между 10:00 p.м. и 6:00 утра каждый день
   
  Начать резервирование ресурсов
  ИМЯ = nightPolicy
  ПОЛЬЗОВАТЕЛИ = ugroup1 ~ user1
  HOSTS = hgroup1 ~ hostB
  TIME_WINDOW = 20: 00-8: 00
  Конечное резервирование ресурсов
     
   
     важно:    
   
   Оператор not (~) не исключает администраторов LSF из политики. 
   
   

  Например:

  1. Определите политику для пользователя: user1 :

   Имя политики: dayPolicy
  Пользователи: user1
  Хосты: hostA
  Временное окно: 8: 00-18: 00
   

  2. Пользователь user1 создает резервирование, соответствующее политике (создатель — user1 , пользователь — user2 ):

   brsvadd -n 1 -m hostA -u user2 -b 10:00 -e 12:00
  user2 # 0 создан.

  3. Пользователь user1 изменяет политику для удаления user1 из списка пользователей:

   Имя политики: dayPolicy
  Пользователи: user3
  Хосты: hostA
  Временное окно: 8: 00-18: 00
   

  4. Как создатель, user1 может изменять резервирование с помощью параметров brsvmod rmhost , -u , -o , -on и -d , но user1 не может добавлять хосты или изменить временное окно бронирования.
  USER_ADVANCE_RESERVATION устарел (lsb.params)

  USER_ADVANCE_RESERVATION в lsb.params является устаревшим в LSF версии 7. Используйте конфигурацию раздела ResourceReservation в lsb.resources для настройки политик предварительного резервирования для вашего кластера.

  Использование предварительного бронирования
  Команды предварительного бронирования

  Используйте следующие команды для работы с предварительным бронированием:

  Brsvadd

  Добавить бронирование

  Brsvdel

  Удалить бронирование

  brsvmod

  Изменить бронирование

  BRSVS

  Просмотр бронирований

  Добавить бронирование
  примечание:

  По умолчанию только администраторы LSF или root могут добавлять или удалять предварительные резервирования.

  1. Запустите brsvadd , чтобы создать новые предварительные резервирования.

  Для бронирования необходимо указать следующее:

  • Количество слотов заданий для резервирования — это количество должно быть меньше или равно фактическому количеству слотов для хостов, определенных в резервировании.
  • Хосты для бронирования
  • Владельцы резервации
  • Период времени для резервирования-либо:
  Укажите хостов для бронирования
  1. Используйте один или оба из следующих параметров brsvadd , чтобы указать хосты, для которых зарезервированы слоты заданий:
  • Параметр -m перечисляет хосты, необходимые для резервирования.Хосты, перечисленные в параметре -m , могут быть локальными для кластера или хостами, арендованными у удаленных кластеров. При отправке задания LSF рассматривает хосты в указанном порядке. Если вы также указываете строку требований к ресурсам с опцией -R , -m не является обязательным.
  • Параметр -R выбирает хосты для резервирования в соответствии со строкой требований к ресурсам. Зарезервированы только хосты, удовлетворяющие выражению требований к ресурсам. -R принимает любую допустимую строку требований к ресурсам, но действует только строка выбора.Если вы также указываете список хостов с опцией -m , -R не является обязательным.
  • Если LSF_STRICT_RESREQ = y в lsf.conf , строка выбора должна соответствовать более строгому синтаксису строки требований к ресурсам, описанному в главе 19 «Определение требований к ресурсам». Синтаксис строгих требований к ресурсам применяется только к разделу select . Это не относится к другим разделам требований к ресурсам ( заказ , rusage , тот же , span или у.е. ).
  Добавить разовое бронирование
  1. Используйте параметры -b и -e команды brsvadd , чтобы указать время начала и время окончания однократного предварительного резервирования. Одноразовое резервирование полезно для выделения хостов конкретному пользователю или группе для критически важных проектов.

  День и время представлены в виде:

   [[[  год    :  ]   месяц    :  ]   день    :  ] час   минут  :   минут
    
  
  со следующими диапазонами:
   
   

  • год : любой год после 1900 (ГГГГ)
  • месяц : 1-12 (ММ)
  • день месяца : 1-31 (дд)
  • час : 0-23 (чч)
  • минут : 0-59 (мм)

  Необходимо указать не менее часа : минут.Год, месяц и день указывать необязательно. Предполагается, что три поля соответствуют дню : час : минута, четыре поля - месяц : день : час : минута и пять полей год : месяц : день : час : минут.

  Если вы не укажете день, LSF предполагает текущий день.Если вы не укажете месяц, LSF предполагает текущий месяц. Если вы указываете год, вы должны указать месяц.

  Вы должны указать время начала и время окончания. Значение времени для -b должно использовать тот же синтаксис, что и значение времени для -e . Время начала должно быть раньше, чем значение времени для -e . Время начала не может быть раньше текущего.

  Следующая команда создает однократное предварительное резервирование 1024 слотов заданий на хосте hostA для пользователя user1 между 6:00 a.м. и 8:00 сегодня:

     brsvadd -n 1024 -m hostA -u user1 -b 6: 0 -e 8: 0  
  Резервирование "user1 # 0" создано
    
  
  Хосты, указанные в параметре  -m , могут быть локальными для кластера или хостами, арендованными у удаленных кластеров.
   
    
  
  Следующая команда создает одноразовое предварительное резервирование 1024 слотов заданий на хосте любого типа для пользователя  user1  с 6:00 до 8:00 сегодня:
   
     brsvadd -n 1024 -R "type == any" -u user1 -b 6: 0 -e 8: 0  
  Резервирование "user1 # 1" создано
    
  
  Следующая команда создает однократное предварительное резервирование, которое резервирует 12 слотов на  hostA  между 6:00 p.м. 1 декабря 2003 г. и в 6:00 31 января 2004 г .:
   
     brsvadd -n 12 -m hostA -u user1 -b 2003: 12: 01: 18: 00 -e
  2004: 01: 31: 06: 00  
  Резервирование user1 # 2 создано
   

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

  День и время представлены в виде:

   [  день    :  ] час [ :     минута  ]
    
  
  со следующими диапазонами:
   
   

  • день недели : 0-6
  • час : 0-23
  • минут : 0-59

  Укажите временное окно одним из следующих способов:

  • час - час
  • час : минута - час : минута
  • день : час : минута - день минут

  Вы должны указать хотя бы час.День недели и минута указывать необязательно. Значения времени начала и времени окончания должны использовать один и тот же синтаксис. Если вы не укажете минуту, LSF принимает первую минуту часа (: 00 ). Если вы не укажете день, LSF предполагает каждый день недели. Если вы все же указываете день, вы также должны указать минуту.

  Если текущее время создания резервирования находится в пределах временного окна резервирования. бронирование становится активным немедленно.

  Когда задание запускается, время завершения задания с предварительным резервированием определяется минимумом из лимита выполнения задания (если он указан), лимитом выполнения очереди (если он указан) или продолжительностью временного окна резервирования.

  Следующая команда создает предварительное резервирование для 1024 слотов заданий на двух хостах hostA и hostB для группы пользователей groupA каждую среду с 12:00 до 3:00 a.м .:

     brsvadd -n 1024 -m "hostA hostB" -g groupA -t "3: 0: 0-3: 3: 0"  
  Резервирование "groupA # 0" создано
    
  
  Следующая команда создает предварительное резервирование 1024 слотов заданий на хосте  hostA  для пользователя  user2  каждый будний день с 12:00 до 14:00:
   
     brsvadd -n 1024 -m "hostA" -u user2 -t "12: 0-14: 0"  
  Резервирование "user2 # 0" создано
    
  
  Следующая команда создает резервирование системы на  hostA  каждую пятницу с 18:00.м. до 20:00:
   
     brsvadd -n 1024 -m hostA -s -t "5: 18: 0-5: 20: 0"  
  Резервирование "система №0" создано
    
  
  Пока резервирование системы активно, никакие другие задания не могут использовать зарезервированные хосты, и LSF не отправляет задания на указанные хосты.
   
    
  
  Следующая команда создает предварительное резервирование для 1024 слотов заданий на хостах  hostA  и  hostB  с более чем 50 МБ пространства подкачки для пользователя  user2  каждый будний день с 12:00 до 2:00 p.м .:
   
     brsvadd -n 1024 -R "swp> 50" -m "hostA hostB" -u user2 -t "12: 0-14: 0"  
  Резервирование "user2 # 1" создано
   

  Добавить открытое бронирование
  1. Используйте опцию -o в brsvadd , чтобы создать открытое предварительное резервирование. Вы должны указать ту же информацию, что и для обычного предварительного бронирования.

  Следующая команда создает одноразовое открытое предварительное резервирование для 1024 слотов заданий на хосте любого типа для пользователя user1 между 6:00 a.м. и 8:00 сегодня:

     brsvadd -o -n 1024 -R "type == any" -u user1 -b 6: 0 -e 8: 0  
  Резервирование "user1 # 1" создано
    
  
  Следующая команда создает открытое предварительное резервирование для 1024 слотов заданий на  hostB  для пользователя  user3  каждый будний день с 12:00 до 14:00:
   
     brsvadd -o -n 1024 -m "hostB" -u user3 -t "12: 0-14: 0"  
  Резервирование "user2 # 0" создано
   

  Укажите название бронирования
  1. Используйте опцию -N в brsvadd , чтобы указать определяемое пользователем имя предварительного резервирования, уникальное в кластере LSF.

  Имя резервирования представляет собой строку из букв, цифр, знаков подчеркивания и дефисов, начинающуюся с буквы. Максимальная длина имени - 39 символов.

  Если определенное пользователем имя предварительного резервирования не указано, LSF создает резервирование с присвоенным системой именем в форме

   имя_пользователя # последовательность
    
  
  Например:
   
  brsvadd -n 3 -M "hostA hostB" -u user2 -b 16: 0 -e 17: 0 -d
  «Продакшн AR-тест»
  Резервирование user2 # 0 (производственный тест AR) создано
  brsvadd -n 2 -N Production_AR -M hostA -u user2 -b 16: 0 -e 17: 0
  -d "Производственный тест AR"
  Резервирование Production_AR (производственный тест AR) создано
    
  
  Если уже существует задание, которое ссылается на резервирование с указанным именем, возвращается сообщение об ошибке: на указанное имя резервирования ссылается задание.
   

  Изменить предварительное бронирование
  1. Используйте brsvmod для изменения резервирований. Укажите идентификатор резервирования для бронирования, которое вы хотите изменить. Например, выполните следующую команду, чтобы увеличить продолжительность с 6:00 до 9:00:

     brsvmod -e "+60" user1 # 0  
  Бронирование "user1 # 0" изменено
    
  
  Администраторы и root могут изменять любые резервирования.Пользователи, перечисленные в разделе ResourceReservation файла  lsb.resources , могут изменять только те резервирования, которые они создали сами.
   
   

  Использование brsvmod для изменения предварительного бронирования

  Используйте brsvmod , чтобы внести следующие изменения в существующее предварительное резервирование:

  • Изменить время начала (отложить или приблизить)
  • Изменить продолжительность окна резервирования (и, следовательно, время окончания)
  • Изменить номера слотов, требуемых резервированием (добавить или удалить слоты с хостами)
  • Изменить список хостов или групп хостов (добавить или удалить хосты или группы хостов)
  • Изменить пользователя или группу пользователей
  • Добавить хосты по требованию к ресурсам ( -R )
  • Изменить тип бронирования (открытое или закрытое)
  • Отключить указанные вхождения повторяющегося резервирования

  Например, предположим, что предварительное резервирование - это промежуток между временем t1 и t2, как показано на следующем рисунке:

  На этом рисунке:

  • В затененном поле показано исходное резервирование
  • Время означает временное окно резервирования
  • t1 - время начала резервирования
  • t2 - время окончания резервирования
  • Размер резервирования означает зарезервированные ресурсы, такие как хосты (слоты) или группы хостов

  Используйте brsvmod для сдвига, увеличения или уменьшения временного окна по горизонтали; увеличивать или уменьшать размер по вертикали.

  Увеличение продолжительности

  Следующая команда создает одноразовое предварительное резервирование для 1024 слотов заданий на хосте hostA для пользователя user1 с 6:00 до 8:00 сегодня:

     brsvadd -n 1024 -m hostA -u user1 -b "6: 0" -e "8: 0"  
  Резервирование "user1 # 0" создано
   

  Выполните следующую команду, чтобы увеличить продолжительность с 6:00 a.м. до 9:00:

     brsvmod -e "+60" user1 # 0  
  Бронирование "user1 # 0" изменено
   

  Добавление хостов к выделению резервирования

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

  Добавление хоста без -n резервирует все доступные слоты на хосте; то есть слоты, которые еще не зарезервированы другими резервированиями.Вы должны указать -n вместе с -m или -R . Параметр -m можно использовать отдельно, если в списке не указана группа узлов. Вы не можете указать -R без -n .

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

  В резервирование системы можно добавлять только хосты ( -m ). Вы не можете добавить слоты ( -n ) в системное резервирование.

  Например:

  • Зарезервировать еще 2 слота у хоста A :

   brsvmod addhost -n2 -m "hostA"
   

• Зарезервировать всего 4 слота для hostA и hostB :

 brsvmod addhost -n4 -m "hostA hostB"
 

• Зарезервируйте еще 4 слота на любых хостах Linux:

 brsvmod addhost -n4 -R "тип == Linux"
 

• Зарезервировать еще 4 слота для любых хостов Linux в группе хостов hostgroup1 :

 brsvmod addhost -n4 -m "hostgroup1" -R "type == linux"
 

• Зарезервировать все доступные слоты на hostA и hostB :

 brsvmod addhost -m "hostA hostB"
 

Следующая команда создает предварительное резервирование 1024 слотов на двух хостах hostA и hostB для группы пользователей groupA каждую среду с 12:00 до 3:00 a.м .:

   brsvadd -n 1024 -m "hostA hostB" -g groupA -t "3: 0: 0-3: 3: 0"  
Резервирование "groupA # 0" создано
   BRSVS  
ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
groupA # 0 user groupA 0/1024 hostA: 0/256 3: 3: 0-3: 3: 0 *
                                    hostB: 0/768
 

Следующие команды резервируют 512 слотов от каждого хоста для резервирования:

   brsvmod addhost -n 256 -m "hostA" groupA # 0  
Бронирование "groupA # 0" изменено
   brsvmod rmhost -n 256 -m "hostB" groupA # 0  
Бронирование "groupA # 0" изменено
 

Удаление хостов из распределения резервирования

Используйте brsvmod rmhost , чтобы удалить хосты или слоты на хостах из исходного распределения резервирования.Вы должны указать либо -n , либо -m . Используйте -n , чтобы указать количество слотов, которые нужно освободить от хоста. Удаление хоста без -n освобождает все зарезервированные слоты на хосте. Спецификация слота должна быть меньше или равна фактическому номеру зарезервированного слота хоста.

Например:

• Удалить 4 зарезервированных слота из hostA

 brsvmod rmhost -n 4 -m "hostA"
 

• Удалите всего 4 слота из hostA и hostB .

 brsvmod rmhost -n 4 -m "hostA hostB"
 

• Выпуск зарезервирован hostA и hostB .

 brsvmod rmhost -m "hostA hostB"
 

• Удалить 4 слота из текущего распределения резервирования.

 brsvmod rmhost -n 4
 

Вы не можете удалить слоты из системного резервирования. Следующая модификация резервирования системы Система №1 отклонена:

 brsvmod rmhost -n 2 -m "hostA" система # 1
 

Сколько слотов или хостов можно удалить, также зависит от количества свободных слотов, пока активно резервирование. brsvmod rmhost не может удалить больше слотов, чем свободное количество на хосте. Например:

   BRSVS  
ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
user1_1 пользователь user1 3/4 hostA: 2/2 1/24/12 / 2-1 / 24/13/0
                                    hostB: 1/2
 

Принимаются следующие модификации, и один слот удален из hostB :

 brsvmod rmhost -m hostB user1_1
brsvmod rmhost -n 1 -m hostB пользователь1_1
 

Отклоняются следующие модификации:

 brsvmod rmhost -n 2 user1_1
brsvmod rmhost -m hostA user1_1
brsvmod rmhost -n 1 -m hostA user1_1
brsvmod rmhost -n 2 -m hostB пользователь1_1
 

Изменение закрытых бронирований

Следующая команда создает открытое предварительное резервирование для 1024 слотов заданий на хосте hostA для пользователя user1 между 6:00 a.м. и 8:00 сегодня.

 brsvadd -o -n 1024 -m hostA -u user1 -b 6: 0 -e 8: 0
Резервирование "user1 # 0" создано
 

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

 brsvmod -on user1 # 0
Бронирование "user1 # 0" изменено
 

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

Используйте brsvmod disable для отключения определенных периодов или экземпляров повторяющегося предварительного резервирования.

Повторяющиеся бронирования могут повторяться либо в дневном, либо в недельном цикле. Для ежедневных бронирований экземпляры резервирования, которые происходят в дни с ограниченными возможностями, будут неактивны. Работы, использующие резервирование, не отправляются в те дни, когда нетрудоспособны. Для других бронирований в эти дни разрешается использовать слоты бронирования. Для резервирования на ночь (активно с 23:00 до 9:00 ежедневно), если резервирование отключено в начальный день экземпляра, резервирование отключается для всего этого экземпляра.

Для еженедельного резервирования, если резервирование отключено в дату начала экземпляра резервирования, то резервирование отключается для всего экземпляра. Например, для еженедельного бронирования с временным окном с 9:00 среды до 22:00. Пятница, в одну конкретную неделю, в четверг резервирование отключается, затем экземпляр резервирования остается активным в течение этой недели. Однако если это же резервирование отключено на среду недели, то резервирование отключается на неделю.

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

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

Например, следующая команда создает повторяющееся предварительное резервирование для 4 слотов на хосте hostA для пользователя user1 с 6:00 до 8:00 каждый день.

 Резервирование "user1 # 0" создано
brsvadd -n 4 -m hostA -u user1 -t "6: 0-8: 0"
 

Выполните следующую команду, чтобы отключить экземпляр резервирования, активный с 1 по 10 декабря 2007 г.

 brsvmod -disable -td "2007: 12: 1-2007: 12: 10" user1 # 0
Бронирование "user1 # 0" изменено
 

Затем администратор может использовать хост hostA для других резервирований в течение этого периода.

 brsvadd -n 4 -m hostA -u user1 -b "2007: 12: 1: 6: 0" -e "2007: 12: 1: 8: 0"
Резервирование "user1 # 2" создано
 

Изменить пользователей и группы пользователей

Используйте brsvmod -u , чтобы изменить пользователя, или brsvmod -g , чтобы изменить группу пользователей, которая может отправлять задания с предварительным резервированием.

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

Brun

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

bslots

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

Как взаимодействуют модификации предварительного бронирования

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

			Запрещать	Модификация
				Время начала	Время окончания	Добавить хостов	Rm Хосты	Пользователь/ Группа пользователей	открыто/ закрыто	Pre cmd	Опубликовать cmd
Один раз	Активный		Нет	Нет	да	да	да	да	да	да	да
	Неактивный		Нет	да	да	да	да	да	да	да	да
Повторяющийся	Вхождения	Все	Нет	да	да	да	да	да	да	да	да
		Указано	да	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет
	Активный экземпляр		Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет

Где: «Да» означает, что модификация поддерживается в сценарии; в противном случае отмечается «Нет».Например, все модификации допустимы в случае, если предварительное бронирование неактивно.

Проверка политики бронирования

В следующей таблице показано, как команды предварительного резервирования интерпретируют конфигурации политики резервирования в lsb.resources :

Команда ...		Проверяет политики для...
		Создатель	Хозяин	TimeWindow
Brsvadd		да	да	да
Brsvdel		Нет	Нет	Нет
brsvmod	-u или -g (смена пользователя)	Нет	Нет	Нет
	addhost	да	да	да
	rmhost	Нет	Нет	Нет
	-b, -e, -t (изменить окно времени)	да	да	да
	-d (описание)	Нет	Нет	Нет
	-o или -on	Нет	Нет	Нет

Политика бронирования проверяется, когда:

• Изменение временного окна резервирования
• Добавление хостов в бронирование

Политика бронирования не проверяется , когда

• Запуск brsvmod для удаления хостов
• Изменение типа бронирования (открытое или закрытое)
• Изменение пользователей или групп пользователей для резервирования
• Изменение описания бронирования
Удалить предварительное бронирование
1. Используйте brsvdel для удаления резервирований.Укажите идентификатор резервирования для резервирования, которое вы хотите удалить.

Например:

   brsvdel user1 # 0  
Резервирование user1 # 0 удаляется
  

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

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

Просмотр бронирований
1. Используйте brsvs для отображения текущих бронирований:

   BRSVS
   ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
user1 # 0 user user1 0/1024 hostA: 0/1024 11/12/6 / 0-11 / 12/8/0
user2 # 0 пользователь user2 0/1024 hostA: 0/1024 12: 0-14: 0 *
groupA # 0 группа groupA - / 2048 hostA: - / 1024 3: 0: 0-3: 3: 0 *
hostB: 0/1024
system # 0 sys system 1024 hostA: 0/1024 5: 18: 0-5: 20: 0 *
  

В столбце TIME_WINDOW:
 
 

• При однократном резервировании поля отображаются через косую черту ( месяц / день / час / минута, ).Например:

 11/12/14 / 0-11 / 12/18/0
 

• При повторяющемся резервировании поля отображаются через двоеточие ( день: час: минута ). Звездочка (*) указывает на повторяющееся резервирование. Например:

 5: 18: 0–5: 20: 0 *
  

В столбцах NCPUS и RSV_HOSTS:
 
 

• При удаленном резервировании подробные сведения не отображаются. Например:

 - / 2048 хост A: - / 1024
 

Показать еженедельник
1. Используйте brsvs -p , чтобы показать еженедельный планировщик для указанных хостов с использованием предварительного резервирования.Ключевое слово all показывает планировщик для всех хостов с резервированием.

Вывод brsvs -p отображается в неделях. Неделя начинается в воскресенье. Срок повторяющегося бронирования не отображается, так как он неограничен. Срок разового бронирования отображается в неделях. Если резервирование длится несколько недель, эти недели отображаются отдельно. Если неделя содержит одноразовое резервирование и повторяющееся резервирование, отображаются временные рамки, поскольку это актуально для одноразового резервирования.

tip:

MAX указывает настроенное максимальное количество слотов заданий для хоста (MXJ определено в lsb.hosts ).

   brsvs -p все
   ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
user1 # 0 user user1 0/1024 hostA: 0/1024 11/12/6 / 0-11 / 12/8/0
user2 # 0 пользователь user2 0/1024 hostA: 0/1024 12: 0-14: 0 *
groupA # 0 группа groupA 0/2048 hostA: 0/1024 3: 0: 0-3: 3: 0 *
hostB: 0/1024
system # 0 sys system 1024 hostA: 0/1024 5: 18: 0-5: 20: 0 *

ХОСТ: hostA (МАКС. = 1024)
Неделя: 11.11. 2009 -17.11. 2009
  Часы: Мин Вс Пн Вт Ср Чт Пт Сб
-------------------------------------------------- -----------------
0: 0 0 0 0 1024 0 0 0
0:10 0 0 0 1024 0 0 0
0:20 0 0 0 1024 0 0 0
...
2:30 0 0 0 1024 0 0 0
2:40 0 0 0 1024 0 0 0
2:50 0 0 0 1024 0 0 0
3: 0 0 0 0 0 0 0 0
3:10 0 0 0 0 0 0 0
3:20 0 0 0 0 0 0 0
...
5:30 0 0 0 0 0 0 0
5:40 0 0 0 0 0 0 0
5:50 0 0 0 0 0 0 0
6: 0 0 1024 0 0 0 0 0
6:10 0 1024 0 0 0 0 0
6:20 0 1024 0 0 0 0 0
...
7:30 0 1024 0 0 0 0 0
7:40 0 1024 0 0 0 0 0
7:50 0 1024 0 0 0 0 0
8: 0 0 0 0 0 0 0 0
8:10 0 0 0 0 0 0 0
8:20 0 0 0 0 0 0 0
...
11:30 0 0 0 0 0 0 0
11:40 0 0 0 0 0 0 0
11:50 0 0 0 0 0 0 0
12: 0 1024 1024 1024 1024 1024 1024 1024 1024
12:10 1024 1024 1024 1024 1024 1024 1024
12:20 1024 1024 1024 1024 1024 1024 1024 1024
...
13:30 1024 1024 1024 1024 1024 1024 1024
13:40 1024 1024 1024 1024 1024 1024 1024
13:50 1024 1024 1024 1024 1024 1024 1024
14: 0 0 0 0 0 0 0 0
14:10 0 0 0 0 0 0 0
14:20 0 0 0 0 0 0 0
...
17:30 0 0 0 0 0 0 0
17:40 0 0 0 0 0 0 0
17:50 0 0 0 0 0 0 0
18: 0 0 0 0 0 0 1024 0
18:10 0 0 0 0 0 1024 0
18:20 0 0 0 0 0 1024 0
...
19:30 0 0 0 0 0 1024 0
19:40 0 0 0 0 0 1024 0
19:50 0 0 0 0 0 1024 0
20: 0 0 0 0 0 0 0 0
20:10 0 0 0 0 0 0 0
20:20 0 0 0 0 0 0 0
...
23:30 0 0 0 0 0 0 0
23:40 0 0 0 0 0 0 0
23:50 0 0 0 0 0 0 0

HOST: hostB (MAX = 1024)
Неделя: 11.11. 2009 -17.11. 2009
  Часы: Мин Вс Пн Вт Ср Чт Пт Сб
-------------------------------------------------- -----------------
0: 0 0 0 0 1024 0 0 0
0:10 0 0 0 1024 0 0 0
0:20 0 0 0 1024 0 0 0
...
2:30 0 0 0 1024 0 0 0
2:40 0 0 0 1024 0 0 0
2:50 0 0 0 1024 0 0 0
3: 0 0 0 0 0 0 0 0
3:10 0 0 0 0 0 0 0
3:20 0 0 0 0 0 0 0
...
23:30 0 0 0 0 0 0 0
23:40 0 0 0 0 0 0 0
23:50 0 0 0 0 0 0 0
 

2. Используйте brsvs -z вместо brsvs -p , чтобы отображать только недельные элементы с конфигурациями резервирования.Строки, отображающие все нули (0), опускаются.

Например:

   brsvs -z все  
ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
user1_1 user1 0/3 hostA: 0/2 12/28/14/30-12/28/15/30
                                           hostB: 0/1
ХОСТ: hostA (МАКС = 2)
Неделя: 23.12.2007 - 29.12.2007
Часы работы: Мин Вс Пн Вт Ср Чт Пт Сб
-------------------------------------------------- --------------------
14:30 0 0 0 0 0 1 0
14:40 0 0 0 0 0 1 0
14:50 0 0 0 0 0 1 0
15: 0 0 0 0 0 0 1 0
15:10 0 0 0 0 0 1 0
15:20 0 0 0 0 0 1 0
 
ХОСТ: hostB (МАКС = 2)
Неделя: 23.12.2007 - 29.12.2007
Часы работы: Мин Вс Пн Вт Ср Чт Пт Сб
-------------------------------------------------- --------------------
14:30 0 0 0 0 0 2 0
14:40 0 0 0 0 0 2 0
14:50 0 0 0 0 0 2 0
15: 0 0 0 0 0 0 2 0
15:10 0 0 0 0 0 2 0
15:20 0 0 0 0 0 2 0
 

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

Строки, следующие за информацией о резервировании, показывают

• Статус бронирования
• Время, когда активен следующий экземпляр повторяющегося резервирования
• Тип бронирования (открытое или закрытое)
• Статус по идентификатору задания любого задания, связанного с указанным резервированием (FINISHED, PEND, RUN или SUSP)

   brsvs -l  
ТИП RSVID ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS TIME_WINDOW
user1_1 # 0 пользователь user1_1 10/10 host1: 4/4 8: 00-22: 00 *
                                                 host2: 4/4
                                                 host3: 2/2
Статус бронирования: активно
Следующий активный период:
        Сб 22 августа 08:00:00 2009 - сб 22 августа 22:00:00 2009
Создатель: user1_1
Тип бронирования: ЗАКРЫТО
ЗАВЕРШЕНО Вакансий: 203 204 205 206 207 208 209 210 211 212
PEND Вакансий: 323 324
РАБОЧИЕ заданий: 31331431631831
21322
Вакансий SUSP: 315 317
 

Показать идентификатор бронирования
1. Используйте bjobs -l , чтобы показать идентификатор резервирования, используемый заданием:

   минет -l
   Задание <1152>, Пользователь , Проект <по умолчанию>, Статус , Очередь
<нормальный>, резервирование , команда 

Пн, 12 ноября, 5:13:21: отправлено с хоста , CWD
;
 

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

bacct -U суммирует все исторические модификации резервирования и отображает информацию, аналогичную команде brsvs :

• ID резервирования, указанный в опции -U.
• Тип бронирования: пользовательский или системный
• Имена пользователей, которые использовали команду brsvadd для создания предварительного бронирования
• Имена пользователей, которые могут использовать предварительное резервирование (с bsub -U )
• Количество зарезервированных слотов
• Список хостов, для которых зарезервированы слоты заданий
• Временное окно для резервирования.
• При однократном резервировании поля отображаются через косую черту ( месяц / день / час / минута, ). Например:

 11/12/14 / 0-11 / 12/18/0
 

• При повторяющемся резервировании поля отображаются через двоеточие ( день: час: минута ). Например:

 5: 18: 0 5: 20: 0
  

Например, следующее предварительное бронирование имеет четыре изменения времени в течение его срока службы.Первоначальное резервирование распространяется на одного пользователя ( user1 ) и один хост ( hostA ) с 1 слотом. Различные модификации изменяют пользователя на  user2 , затем обратно на  user1 , добавляет, затем удаляет 1 слот из резервирования.
 
   bacct -U user1 # 1  
Учет предварительных бронирований, а именно:
  - учитываются по идентификаторам предварительного бронирования user1 # 1,
  - с учетом предварительных бронирований, созданных пользователем user1,
---------------------------- РЕЗЮМЕ --------------------- -------
RSVID: user1 # 1
ТИП: пользователь
СОЗДАТЕЛЬ: user1
Общее количество вакансий: 0
Общее затраченное время ЦП: 0.0 секунд
Максимальный объем памяти задания: 0,0 МБ
Максимальный размер подкачки задания: 0,0 МБ
Общее время активности: 0 час 6 минут 42 секунды
------------------------ Конфигурация 0 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 1 пользователь user1 user1 1 hostA: 1
Активное время с этой конфигурацией: 0 часов 0 минут 16 секунд
------------------------ Конфигурация 1 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 1 пользователь user1 user2 1 hostA: 1
Активное время с этой конфигурацией: 0 часов 0 минут 24 секунды
------------------------ Конфигурация 2 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 1 пользователь user1 user2 1 hostA: 1
Активное время с этой конфигурацией: 0 час 1 минута 58 секунд
------------------------ Конфигурация 3 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 1 пользователь user1 user1 2 hostA: 2
Активное время с этой конфигурацией: 0 час 1 минута 34 секунды
------------------------ Конфигурация 4 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 1 пользователь user1 user1 1 hostA: 2
Активное время с этой конфигурацией: 0 час 2 минуты 30 секунд
  

Следующее резервирование ( user2 # 0 ) имеет однократную модификацию в течение своего времени жизни.Исходный имеет область действия одного пользователя ( user2 ) и одного хоста ( hostA ) с 1 слотом; модификация изменяет пользователя на  user3 .
 
   bacct -U user2 # 0  
Учет предварительных бронирований, а именно:
  - учитываются по всем идентификаторам предварительного бронирования:
  - учитываются предварительные бронирования, созданные всеми пользователями:
--------------------------- РЕЗЮМЕ ---------------------- ---
RSVID: user2 # 0
ТИП: пользователь
СОЗДАТЕЛЬ: user2
Общее количество вакансий: 1
Общее затраченное время ЦП: 5.0 секунд
Максимальный объем памяти задания: 1,7 МБ
Максимальный размер подкачки задания: 7,5 МБ
Общее время активности: 2 часа 0 минут 0 секунд
------------------------ Конфигурация 0 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 0 пользователь user2 user2 1 hostA: 1
Активное время с этой конфигурацией: 1 час 0 минут 0 секунд
------------------------ Конфигурация 1 ------------------------
ТИП RSVID СОЗДАТЕЛЬ ПОЛЬЗОВАТЕЛЬ NCPUS RSV_HOSTS
user1 # 0 пользователь user2 user3 1 hostA: 1
Активное время с этой конфигурацией: 1 час 0 минут 0 секунд
 

Отправляйте и изменяйте вакансии с помощью предварительного бронирования
1. Используйте опцию -U для bsub для отправки заданий с идентификатором резервирования.Например:

   bsub -U user1 # 0 myjob  
  

Задание может использовать только хосты, зарезервированные резервированием  user1 # 0 . По умолчанию LSF выбирает только хосты в резервировании. Используйте опцию  -m , чтобы указать конкретные хосты в списке хостов, зарезервированных при резервировании; вы можете выбирать только из тех хостов, которые были включены в исходное резервирование.
 
  

Если вы не укажете хосты ( bsub -m ) или требования к ресурсам ( bsub -R ), требование к ресурсам по умолчанию - выбрать хосты любого типа (вместо этого LSF предполагает  "type == any" ). of  "type == local"  в качестве строки выбора по умолчанию).
  

Если вы позже удалите предварительное резервирование, пока оно еще активно, все ожидающие задания сохранят атрибут  "type == any" .
 
  

Для задания можно использовать только одно резервирование. Нет ограничений на количество вакансий, которые могут быть отправлены в резервирование; однако количество слотов, доступных на хостах в резервировании, может закончиться. Например, резервирование  user2 # 0  резервирует 1024 слота на  hostA . Когда все 1024 слота на  hostA  используются заданиями, ссылающимися на  user2 # 0 ,  hostA  больше не доступен для других заданий с использованием резервирования  user2 # 0 .У любого отдельного пользователя или группы пользователей может быть не более 100 идентификаторов резервирования.
 
  

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

Изменить идентификатор резервирования вакансии

Предварительные требования: для выполнения этой задачи вы должны быть администратором.

1. Используйте опцию -U команды bmod , чтобы изменить задание на другой идентификатор резервирования.

Например:

   bmod -U user1 # 0 1234  
 

2. Чтобы отменить резервирование, используйте опцию -Un для bmod .

Например:

   bmod -Un 1234  
  

Используйте команду  bmod -Un , чтобы отсоединить запущенное задание от неактивного   открытого резервирования  . После отсоединения задание планируется как обычное.
 

Ограничения на использование ресурсов заданий и разбиение заданий

На задание, использующее резервирование, распространяются все ограничения на использование ресурсов задания. Если на конкретном хосте в резервировании достигнут предел, задания, использующие это резервирование, не могут начаться на этом хосте.

Задание с предварительным резервированием отправляется в свое резервирование, даже если предел выполнения или расчетное время выполнения задания превышает оставшееся активное время резервирования.Например, если у задания лимит выполнения составляет 1 час, а оставшееся время активности резервирования составляет 1 минуту, задание все равно отправляется в резервирование. Если резервирование закрыто, задание прекращается по истечении срока резервирования.

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

Выгодное предварительное бронирование

Вытеснение с предварительным резервированием позволяет заданиям с предварительным резервированием использовать слоты, зарезервированные резервированием. Слоты, занятые незадействованными заданиями, могут быть вытеснены, когда резервирование становится активным.

Без модификации с помощью brsvmod приоритетное приоритетное резервирование запускается не более одного раза за период резервирования (в случае единовременного резервирования существует только один период) всякий раз, когда выполняются одновременно из следующих условий:

• Резервирование активно
• По крайней мере одно задание, связанное с предварительным резервированием, ожидает или приостановлено

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

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

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

Когда задание вытесняется для предварительного резервирования, оно может возобновиться на хосте только после того, как завершится предварительное резервирование или какое-либо другое задание без предварительного резервирования завершится на хосте.

Например, кластер с одним хостом имеет 10 слотов, причем на хост отправляются 9 заданий без предварительного резервирования (для каждого из которых требуется один слот). Создается предварительное резервирование, которое использует 5 слотов на хосте, и одно задание отправляется в резервирование. Когда резервирование становится активным, 4 задания без предварительного резервирования приостанавливаются, и запускается задание с предварительным резервированием.

Принудительный запуск задания до того, как резервирование станет активным

Администраторы LSF могут использовать brun для принудительного запуска заданий до того, как резервирование станет активным, но задание должно завершиться до истечения временного окна резервирования.

Например, если администратор принудительно запускает задание с резервированием за час до его активации, а период резервирования составляет 3 часа, вступает в силу 4-часовой предел выполнения.

Хост-перекресток и предварительное бронирование

Когда ENABLE_HOST_INTERSECTION = y в lsb.params , LSF находит любое существующее пересечение с хостами, указанными в очереди, и теми, которые указаны при отправке задания с помощью bsub -m и / или хостов с предварительным резервированием.При указании таких ключевых слов, как все , allremote и другие , LSF находит существующее пересечение доступных хостов, и задание выполняется, а не отклоняется.

Предварительное бронирование по кластерам

Вы можете создать и использовать предварительное резервирование для модели пересылки заданий MultiCluster. Чтобы включить эту функцию, необходимо обновить все кластеры до LSF версии 7 или новее.

См. Использование платформы LSF MultiCluster для получения дополнительной информации.

Изменяемые размеры вакансий и предварительное бронирование

Как и обычные задания, задания с изменяемым размером, связанные с предварительным резервированием, могут быть отправлены только после того, как резервирование станет активным, и минимальный запрос процессора может быть удовлетворен. Запрос на выделение обрабатывается как обычное задание предварительного резервирования, которое полагается на слоты, доступные для резервирования. Если предварительное резервирование получает больше ресурсов путем модификации ( brsvmod addhost ), эти ресурсы могут быть использованы немедленно отложенными запросами на выделение.

В следующей таблице приведены взаимосвязи жизненного цикла AR и запросов заданий с изменяемым размером:

Предварительное бронирование		Работа с изменяемым размером	Запрос на размещение
Одноразовый срок истек / удален	Открыть	ВЫПОЛНИТЬ-> SSUSP-> ВЫПОЛНИТЬ	Отложено до выполнения задания
	Закрыто	Удаленный	Удаленный
Рекуррент истек / удален	Открыть	SSUSP до следующего экземпляра	Отложено до следующего запуска задания
	Закрыто	Удаленный	Удаленный

К тому времени, когда срок действия резервирования истек или он удален, изменение статуса задания с изменяемым размером на SSUSP блокирует планирование запроса на выделение задания с изменяемым размером.

Освобожденные слоты из задания с изменяемым размером могут быть повторно использованы другими заданиями в резервировании.

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

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

Расчетные единицы и предварительное бронирование

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

В случае эксклюзивных заданий вычислительного модуля (с требованием ресурсов cu [ excl] ) предварительное резервирование может повлиять на хосты вне предварительного резервирования, но в том же вычислительном модуле, как показано ниже:

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

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

Резервирование зональных ресурсов Compute Engine

Создание резервирования для экземпляров виртуальных машин (ВМ) в определенной зоне, с использованием пользовательских или предопределенных типов машин, с дополнительными графическими процессорами или без них, или локальные SSD, чтобы обеспечить доступность ресурсов для ваших рабочих нагрузок, когда вам нужно их.После создания бронирования вы начинаете платить за зарезервированный ресурсы немедленно, и они остаются доступными для использования в вашем проекте на неопределенный срок, пока бронирование не будет удалено.

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

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

Прежде чем начать

Преимущества

Бронирование дает следующие преимущества:

• Машины всегда доступны, даже если вы не используете их сразу.

• Без ограничений по времени. Создайте бронирование в любое время и удалите его в любой момент. пора перестать за это платить.

  Примечание: Если резервирование прикреплено к обязательству, то резервирование не может быть удален, пока не истечет договор обязательства.

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

Ограничения и ограничения

Бронирование имеет следующие ограничения:

• Резервирование распространяется только на Compute Engine, Dataproc и Использование виртуальной машины Google Kubernetes Engine.
• Бронирование не распространяется на следующие ресурсы:
  • f1-micro , g1-small , e2-micro , e2-small , e2-medium типы машин
  • вытесняемые виртуальные машины
  • Индивидуальные узлы
  • Другие службы, не указанные выше, например Cloud SQL и Dataflow
• Вы можете зарезервировать до 1000 экземпляров ВМ за одно резервирование.
• У вас должна быть достаточная квота в вашем проекте для ресурсов, которые вы резервирование.Если резервирование выполнено успешно, квота для этого ресурса составляет взимается соответственно.
• Ресурсы выделяются при создании резервирования. Если здесь недостаточно ресурсов в зоне во время запроса, резервирование не выполняется из-за ошибки недостаточной емкости.
• В сочетании со скидкой за обязательное использование:
  • Для обязательного использования цены со скидкой на графические процессоры и локальные твердотельные накопители, оговорка должен быть создан при покупке обязательства.
  • Если резервирование прикреплено к обязательству, резервирование не может быть удалено.
  • Для графических процессоров K80 вы можете приобрести только годовое обязательство.
• Бронирование, не связанное со скидкой за обязательное использование, может быть приостановлено на любой продолжительности, но взимается такая же минимальная плата в размере 1 минуты, как и для обычного экземпляры.

Как работает бронирование

Создайте резервирование для резервирования необходимых экземпляров виртуальных машин. После создания резервирование, резервирование гарантирует, что эти ресурсы всегда доступны для вас. В процессе создания вы можете выбрать способ бронирования должен использоваться.Например, вы можете выбрать автоматическое резервирование. применяется к любым новым или существующим экземплярам, ​​которые соответствуют properties (поведение по умолчанию) или укажите, что только конкретный экземпляр ВМ может потреблять резервирование.

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

• Зона
• Тип машины (ядра и память)
• Минимальная платформа ЦП
• Тип графического процессора
• Количество графических процессоров
• Локальный интерфейс SSD
• Размер локального SSD

Если экземпляр виртуальной машины соответствует свойствам резервирования, поведение по умолчанию чтобы все существующие и новые экземпляры виртуальных машин использовали резервирование автоматически если не указано иное.Например, по умолчанию, если вы создаете бронирование для 10 экземпляров custom-8-10240 , и у вас уже есть 5 подходящих custom-8-10240 экземпляров, то эти 5 экземпляров потребляют 5 из оговорки. Если вы создадите дополнительные 3 совпадающих экземпляра, тогда еще 3 резервирования потребляются.

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

• Чтобы создать резервирование, которое вы не хотите использовать автоматически, используйте опцию specificReservationRequired .Эти оговорки могут использоваться только в том случае, если вы явно укажете резервирование во время экземпляра создание.
• Чтобы указать, что вы хотите, чтобы экземпляр использовал резервирование, используйте servationAffinity опция при создании экземпляра или в экземпляре шаблон. Вы можете указать, что экземпляр автоматически потребляет из любого соответствующее резервирование, не расходуется автоматически из сопоставления резервирования, или потребляет только из определенного бронирования.

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

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

Создание бронирования

Создайте резервирование для экземпляров ВМ с помощью консоли, инструмента командной строки gcloud , или API. По умолчанию все экземпляры ВМ, соответствующие свойствам резервирования. автоматически использовать это резервирование. Чтобы создать бронирование, которое не потребляется автоматически, используйте параметр specificReservationRequired .

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

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

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• compute.reservations.create по проекту
Консоль

1. В консоли Google Cloud перейдите на страницу Обязательные скидки на использование .

   Перейти на скидки за обязательное использование

2. Щелкните Создать резервирование , чтобы создать автономное резервирование с никаких родительских обязательств.

   Примечание: Для получения информации о том, как приобрести обязательство с помощью прилагаемое бронирование, которое требуется, если вы хотите при обязательном использовании скидки на графические процессоры и локальные твердотельные накопители, см. Сочетание бронирования со скидками за обязательное использование.

3. Укажите название вашего бронирования.

4. Если вы хотите использовать ресурсы этого резервирования только при создании соответствующие экземпляры, которые специально нацелены на это бронирование по имени, под Использовать с экземпляром ВМ , выберите Выберите конкретное резервирование .

5. Выберите область и зону , где вы хотите зарезервировать ресурсы.

6. Укажите Число экземпляров ВМ, которые вы хотите зарезервировать.

7. Укажите ресурсы, которые вы хотите зарезервировать для каждого экземпляра:

   • Если у вас есть шаблон экземпляра, щелкните Использовать шаблон экземпляра и выберите шаблон экземпляра из списка.
   • В противном случае нажмите Укажите тип машины .
     1. Для предопределенных типов машин выберите из списка то, что вам нужно.
     2. Для пользовательских типов машин, включая минимальную платформу ЦП, или для добавьте графические процессоры, нажмите Настроить и сделайте свой выбор.
     3. При желании укажите количество Local SSD дисков, которые вы хотите добавить к каждому экземпляру и указать Тип интерфейса использовать.

8. Щелкните Создать , чтобы создать резервирование.

gcloud

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

 gcloud compute reservations создать  RESERVATION_NAME  \
    --machine-type =  MACHINE_TYPE  \
    --min-cpu-platform  MINIMUM_CPU_PLATFORM  \
    --vm-count =  NUMBER_OF_VMS  \
    --accelerator = count =  NUMBER_OF_ACCELERATORS , type =  ACCELERATOR_TYPE  \
    --local-ssd = size =  SIZE_IN_GB , interface =  ИНТЕРФЕЙС  \
    --require-specific-резервация \
    --zone =  ЗОНА 
 

Заменить следующее:

• RESERVATION_NAME : название бронирования для Создайте.
• MACHINE_TYPE : тип аппарата. Например, н1-стандарт-2 . Для нестандартных типов машин используйте формат custom - CPUS - ПАМЯТЬ , заменив следующее:
  • CPUS : количество виртуальных ЦП.
  • ПАМЯТЬ : общий объем памяти для этого экземпляра. Объем памяти должен быть кратен 256 МБ и должен предоставляться в МБ; например, 5 ГБ памяти - это 5120 МБ: custom-4-5120 .Полный список ограничений см. Характеристики для нестандартных типов машин.
• MINIMUM_CPU_PLATFORM : минимальный процессор для использования для каждого экземпляра.
• NUMBER_OF_VMS : количество экземпляров ВМ для бронировать.
• NUMBER_OF_ACCELERATORS : количество графических процессоров для добавить, для каждого экземпляра.
• ACCELERATOR_TYPE : тип ускорителя.
• SIZE_IN_GB : объем в ГБ локального SSD. прикрепить к каждому экземпляру.Сумма должна быть кратной 375.
• ИНТЕРФЕЙС : тип интерфейса, который требуется локальный SSD для каждого используемого экземпляра. Допустимые варианты: scsi и nvme .
• ЗОНА : зона, в которой резервируются ресурсы.

При желании добавьте флаг --require-specific-reservation , чтобы указать что только экземпляры виртуальных машин, которые явно нацелены на это резервирование, могут его использовать. Для получения дополнительной информации о параметрах конфигурации для использования зарезервированных ресурсы, см. Как работает резервирование.

Например, чтобы сделать заказ по номеру us-central1-a , который можно только используется, когда это резервирование специально нацелено, используйте команду аналогично следующему. В этом примере резервируется 10 пользовательских машин, каждая с 8 виртуальными ЦП Intel Haswell (или новее), 10 ГБ памяти, 2 графических процессора V100 и локальный твердотельный накопитель 375 ГБ:

 gcloud compute reservations создать мое резервирование \
    --machine-type = custom-8-10240 \
    --min-cpu-platform "Intel Haswell" \
    --vm-count = 10 \
    --accelerator = count = 2, type = nvidia-tesla-v100 \
    --local-ssd = size = 375, interface = scsi \
    --require-specific-резервация \
    - зона us-central1-c 

Чтобы увидеть список всех доступных флагов, см. gcloud compute reservations создать Справка.

API

В API создайте запрос POST к reservations.insert метод. В теле запроса укажите следующие параметры:

 POST https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / reservations

{
  "name": " RESERVATION_NAME ",
  "specificReservation": {
    "count": " NUMBER_OF_VMS ",
    "instanceProperties": {
      "machineType": " MACHINE_TYPE ",
      "minCpuPlatform": " MINIMUM_CPU_PLATFORM ",
      "guestAccelerators": [
        {
          "acceleratorCount": " NUMBER_OF_ACCELERATORS ",
          "acceleratorType": " ACCELERATOR_TYPE "
        }
      ],
      "localSsds": [
        {
          "diskSizeGb": " SIZE_IN_GB ",
          «интерфейс»: « ИНТЕРФЕЙС »
        }
      ]
    }
  }
} 

Заменить следующее:

• PROJECT_ID : идентификатор проекта для запроса.
• ЗОНА : зона, в которой резервируются ресурсы.
• RESERVATION_NAME : название бронирования создавать.
• NUMBER_OF_VMS : количество экземпляров ВМ для бронировать.
• MACHINE_TYPE : предопределенный или настраиваемый тип аппарата. Например, н1-стандарт-2 . Для нестандартных типов машин используйте формат custom - CPUS - ПАМЯТЬ , заменив следующее:
  • CPUS : количество виртуальных ЦП.
  • ПАМЯТЬ : общий объем памяти для этого экземпляра. Объем памяти должен быть кратен 256 МБ и должен предоставляться в МБ; например, 5 ГБ памяти - это 5120 МБ: custom-4-5120 . Полный список ограничений см. Характеристики для нестандартных типов машин.
• MINIMUM_CPU_PLATFORM : минимальный процессор для использования для каждого экземпляра.
• NUMBER_OF_ACCELERATORS : количество графических процессоров для добавить, для каждого экземпляра.
• ACCELERATOR_TYPE : тип ускорителя.
• SIZE_IN_GB : объем в ГБ локального SSD. прикрепить к каждому экземпляру. Сумма должна быть кратной 375.
• ИНТЕРФЕЙС : тип интерфейса, который вы хотите локальный SSD для каждого используемого экземпляра. Допустимые варианты: scsi и nvme .

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

Например, чтобы сделать заказ по номеру us-central1-a , который можно только используется, когда это резервирование специально нацелено, используйте команду аналогично следующему. В этом примере резервируется 10 пользовательских машин, каждая с 8, Intel Haswell (или более поздними) vCPU, 10 ГБ памяти, 2 графических процессора V100 и локальный SSD на 375 ГБ:

 ЗАПИСЬ https: //compute.googleapis.com / compute / v1 / projects / my-project / zone / us-central1-a / reservations

{
  "name": "бронь-1",
  "specificReservation":
  {
    «count»: «10»,
    "instanceProperties":
    {
      "machineType": "custom-8-10240",
      «minCpuPlatform»: «Intel Haswell»,
      "guestAccelerators":
      [
        {
          "acceleratorCount": 2,
          "acceleratorType": "nvidia-tesla-v100"
        }
      ],
      "localSsds":
      [
        {
          "diskSizeGb": "375",
          «интерфейс»: «SCSI»
        }
      ]
    }
  },
    "specificReservationRequired": верно 
} 

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

Использование зарезервированных экземпляров

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

Для использования резервирования созданные вами экземпляры должны соответствовать этому свойства экземпляра бронирования.Видеть Как работает бронирование.

Получение экземпляров из любого совпадающего резервирования

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

При создании резервирования исключите --require-specific-reserve флаг, так что соответствующие экземпляры могут потреблять из этих резервирований автоматически.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• compute.reservations.create по проекту
• compute.instances.create на проекте
• compute.instances.updateShieldedVmConfig , если вы планируете создать Экземпляр экранированной виртуальной машины, и вы хотите чтобы иметь возможность изменять любые настройки экранированной виртуальной машины
• вычислений.network.use в проекте при использовании устаревшего сеть
• compute.subnetworks.use либо во всем проекте, либо в выбранной подсети (Сети VPC)
• compute.networks.useExternalIp в проекте, если вам нужно назначить внешний IP-адрес (временный или статический) экземпляра, использующего устаревшую сеть
• compute.subnetworks.useExternalIp либо для всего проекта, либо для выбранного подсеть, если вам нужно назначить экземпляру внешний IP-адрес (временный или статический) с использованием сети VPC
• вычислений.адреса. используйте в проекте, если указываете статический адрес в проект
• compute.instances.setMetadata при установке метаданных
• compute.instances.setTags в экземпляре при установке тегов
• compute.instances.setLabels на экземпляре, если параметр этикетки
• compute.images.useReadOnly на образе при создании нового корня постоянный диск
• compute.disks.create в проекте при создании нового корня постоянный диск с этим экземпляром
• вычислений.disks.useReadOnly на диске при подключении существующего постоянный диск в режиме только для чтения
• compute.disks. Используйте на диске при подключении существующего диска в режим чтения / записи
• compute.disks.set Ярлыки на диске, если настройка этикетки
• compute.snapshots.create в проекте для создания нового снимок при создании экземпляра из снимка
• compute.snapshots.useReadOnly на снимке при создании экземпляра из снимка

Консоль

1. Создайте открытое резервирование.

   1. В облачной консоли перейдите к Обязательные скидки на использование страница.

      Перейти на скидки за обязательное использование

   2. Чтобы создать автономное резервирование без родительского обязательства, нажмите Создать резерв .

      Примечание: Для получения информации о том, как приобрести обязательство с помощью прилагаемое бронирование, которое требуется, если вы хотите при обязательном использовании скидки на графические процессоры и локальные твердотельные накопители, см. Сочетание бронирования со скидками за обязательное использование.

   3. Назовите свое бронирование, например: резерв-01 .

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

   5. Выберите область и зону , где вы хотите зарезервировать Ресурсы.

   6. Укажите Число экземпляров ВМ, которые вы хотите зарезервировать.

   7. Укажите ресурсы, которые должны быть у каждого экземпляра:

      • Количество виртуальных ЦП
      • Минимальная платформа ЦП
      • Объем памяти
      • графических процессора
      • Локальный SSD (при необходимости)

   8. Нажмите кнопку Создать , чтобы создать резервирование.

2. Создайте экземпляр виртуальной машины, нацеленный на любое открытое резервирование и соответствующий свойства экземпляра в резервации-01 , включая зону, тип машины (количество виртуальных ЦП и объем памяти), минимальная платформа ЦП, графический процессор количество и тип, а также интерфейс и размер локального SSD.

   1. В облачной консоли перейдите на страницу экземпляров виртуальных машин .

      Перейти к инстансам ВМ

   2. Выберите свой проект и щелкните Продолжить .

   3. Щелкните Создать экземпляр .

   4. Укажите Имя для вашего экземпляра.

   5. Укажите Тип машины , который соответствует свойствам бронирование-01 . Например, если вы указали минимальный процессор платформы или графических процессоров в резервировании, чтобы потреблять резервирование, вы должны настроить этот экземпляр, чтобы он соответствовал бронирование.

   6. Если ваше резервирование включает локальные твердотельные накопители, до Диски , нажмите Добавить новый диск в добавить локальные SSD которые соответствуют локальному интерфейсу SSD и сумме резервирования.

   7. Под управлением , под Резервирование , выберите автоматически использовать созданное резервирование .

   8. Щелкните Создать .

gcloud

1. Создайте открытое резервирование с именем резервирование-01 .

   gcloud compute reservations создать резервирование-01 \
       --machine-type = n2-standard-32 \
       --min-cpu-platform "Intel Cascade Lake" \
       --vm-count = 2 \
       --zone = us-central1-a
    

2. Создайте экземпляр виртуальной машины, нацеленный на любое открытое резервирование и соответствующий свойства экземпляра в резервации-01 , включая зону, тип машины (количество виртуальных ЦП и объем памяти), минимальная платформа ЦП, графический процессор количество и тип, а также интерфейс и размер локального SSD.

   Вычислительные экземпляры gcloud создают экземпляр-1 \
       --machine-type = n2-standard-32 \
       --min-cpu-platform "Intel Cascade Lake" \
       --zone = us-central1-a \
         --reservation-affinity = любое 
    

API

1. Создайте открытое резервирование с именем резервирование-01 .

    ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/reservations
   
   {
     "имя": "бронь-01",
     "specificReservation": {
       "count": "2",
       "instanceProperties": {
         "machineType": "n2-стандарт-32",
         "minCpuPlatform": "Intel Cascade Lake",
       }
     },
       "specificReservationRequired": ложь 
   }
    

2. Создайте экземпляр виртуальной машины, нацеленный на любое открытое резервирование и соответствующий свойства экземпляра в резервации-01 , включая зону, тип машины (количество виртуальных ЦП и объем памяти), минимальная платформа ЦП, графический процессор количество и тип, а также интерфейс и размер локального SSD.

    ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances
   
   {
     "имя": "экземпляр-1",
     "machineType": "зоны / us-central1-a / machineTypes / n2-standard-32",
     "minCpuPlatform": "Intel Cascade Lake",
       "BookingAffinity":
     {
       "consumerReservationType": "ANY_RESERVATION"
     }, 
     ...
   }
    

Получение экземпляров из определенного резервирования

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

При создании резервирования укажите, что резервирование использовать нельзя. автоматически. Затем создайте виртуальные машины которые специально предназначены для этого бронирования и соответствуют его свойствам.

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

Например, создайте конкретное резервирование с именем резервирование-02 , а затем создать соответствующий экземпляр, нацеленный на это резервирование и соответствующий свойства экземпляра бронирования.

Консоль

1. Создание резервирования с ресурсами, которые могут использоваться только экземплярами которые специально нацелены на это бронирование по имени.

   1. В облачной консоли перейдите к Обязательные скидки на использование страница.

      Перейти на скидки за обязательное использование

   2. Щелкните Создать резервирование , чтобы создать автономное резервирование у которого нет родительских обязательств.

      Примечание: Для получения информации о том, как приобрести обязательство с помощью прилагаемое бронирование, которое требуется, если вы хотите при обязательном использовании скидки на графические процессоры и локальные твердотельные накопители, см. Сочетание бронирования со скидками за обязательное использование.

   3. Назовите свое бронирование, например: резерв-02 .

   4. Менее Используйте с экземпляром ВМ , отметьте Выберите конкретный резервирование , так что только соответствующие экземпляры, которые специально нацелить это резервирование по имени можно использовать это резервирование.

   5. Выберите область и зону , где вы хотите зарезервировать Ресурсы.

   6. Укажите Число экземпляров ВМ, которые вы хотите зарезервировать.

   7. Укажите ресурсы, которые должны быть у каждого экземпляра:

      • Количество виртуальных ЦП
      • Минимальная платформа ЦП
      • Объем памяти
      • графических процессора
      • Локальный SSD

   8. Щелкните Создать .

2. Создайте экземпляр виртуальной машины, нацеленный на это конкретное резервирование по имени.

   Убедитесь, что свойства экземпляра соответствуют свойствам экземпляра это конкретное резервирование, включая зону, тип машины (количество виртуальных ЦП и объем памяти), минимальная платформа ЦП, количество и тип ГП, а также локальный Интерфейс и размер SSD.

   1. В облачной консоли перейдите на страницу экземпляров виртуальных машин .

      Перейти к инстансам ВМ

   2. Выберите свой проект и щелкните Продолжить .

   3. Нажмите кнопку Создать экземпляр .

   4. Укажите Имя для вашего экземпляра.

   5. Укажите Тип машины , который соответствует свойствам бронирование-01 . Например, если вы указали минимальный процессор платформы в резервации, то для использования резервации вы необходимо настроить этот экземпляр в соответствии с резервированием.

   6. Если ваше резервирование включает локальные твердотельные накопители, в разделе Диски щелкните Добавить новый диск в добавить локальные SSD которые соответствуют локальному интерфейсу SSD и сумме резервирования.

   7. Под управлением , под Резервирование , выберите доступный бронирование с совпадающими свойствами, например: резерв-02 .

   8. Щелкните Create , чтобы создать экземпляр.

gcloud

1. Создайте резервирование с именем резервирование-02 с - флаг для резервирования, специфичного для требования. Эти зарезервированные ресурсы могут быть используется только экземплярами, которые специально нацелены на это резервирование по имени.

   gcloud compute reservations создать резервирование-02 \
       --machine-type = n2-standard-32 \
       --min-cpu-platform "Intel Cascade Lake" \
       --vm-count = 10 \
       --zone = us-central1-a \
         - резервирование с учетом требований 
    

2. Создайте экземпляр виртуальной машины, нацеленный на резервирование-02 по имени, используя - флаги сродства резервирования и - флаги сохранения .

   Убедитесь, что свойства экземпляра соответствуют экземпляру резервирования. свойства, включая зону, тип машины (количество виртуальных ЦП и память количество), минимальная платформа ЦП, количество и тип графического процессора и локальный SSD интерфейс и размер.

   Вычислительные экземпляры gcloud создают экземпляр-2 \
       --machine-type = n2-standard-32 \
       --min-cpu-platform "Intel Cascade Lake" \
       --zone = us-central1-a \
         --reservation-affinity = specific \
       --reservation = резервирование-02 
    

API

1. Создайте резервирование с именем резервирование-02 с specificReservationRequired Поле установлено на true .

    ЗАПИСЬ https: //compute.googleapis.com / compute / v1 / projects / my-project / zone / us-central1-a / reservations
   
   {
     "имя": "бронь-02",
     "specificReservation": {
       «count»: «10»,
       "instanceProperties": {
         "machineType": "n2-стандарт-32",
         "minCpuPlatform": "Intel Cascade Lake",
       }
     },
       "specificReservationRequired": верно 
   } 

2. Создайте экземпляр виртуальной машины, нацеленный на резервирование-02 по имени, используя резервное поле Affinity .

   Убедитесь, что свойства экземпляра соответствуют экземпляру резервирования. свойства, включая зону, тип машины (количество виртуальных ЦП и память количество), минимальная платформа ЦП, количество и тип графического процессора и локальный SSD интерфейс и размер.

    ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances
   
   {
     "имя": "экземпляр-2",
     "machineType": "зоны / us-central1-a / machineTypes / n2-standard-32",
     "minCpuPlatform": "Intel Cascade Lake",
       "BookingAffinity":
     {
       "consumerReservationType": "SPECIFIC_RESERVATION",
       "ключ": "compute.googleapis.com/reservation-name",
       "значения":
       ["бронь-02"
       ]
     }, 
     ...
   } 

Создание экземпляров без использования резервирований

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

Консоль

1. Создайте экземпляр, который явно не использует резервирование.

   1. В облачной консоли перейдите на страницу экземпляров виртуальных машин .

      Перейти к инстансам ВМ

   2. Щелкните Создать экземпляр .

   3. Создайте экземпляр как обычно.

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

   5. Щелкните Создать .

gcloud

Создайте экземпляр, из резервации явно не потребляет.

Вычислительные экземпляры gcloud создают instance-3  --reservation-affinity = none 
 

Или создайте экземпляр, который не соответствует свойствам экземпляра ни в одном ваших бронирований.Чтобы просмотреть свойства бронирования, см. перечисление и описание оговорок.

API

Создайте экземпляр, который из резервации явно не потребляет.

 ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances

{
  "machineType": "зоны / us-central1-a / machineTypes / n2-standard-16",
  "имя": "экземпляр-3",
    "BookingAffinity":
  {
    "consumerReservationType": "NO_RESERVATION"
  }, 
  ...
} 

Или создайте экземпляр, который не соответствует свойствам экземпляра ни в одном ваших бронирований.Чтобы просмотреть свойства бронирования, см. перечисление и описание оговорок.

Обеспечение использования резерваций

Если вы не можете использовать зарезервированные ресурсы, просмотрите свойства бронирования и экземпляра характеристики. Чтобы проверить, соответствуют ли свойства экземпляра резервированию properties, создайте конкретное резервирование, а затем создайте экземпляр, который нацелен на это конкретное резервирование.

Проверить свойства бронирования

Свойства экземпляра резервирования должны совпадать со свойствами в вашем экземпляре. команда создания.Для проверки:

1. Проверить свойства бронирования специально для:

   • зона
   • конкретное бронирование Требуется
     • Если установлено значение true , ваша команда создания экземпляра должна нацелить это бронирование по имени.
   • машина Тип
   • guestAccelerators.acceleratorType
   • guestAccelerators.acceleratorCount
   • мин Платформа процессора
     • Если у вас есть экземпляр ВМ с minCpuPlatform , и вы хотите создать резервирование, использующее этот экземпляр, создать резервирование с соответствующими свойствами, включая соответствующую minCpuPlatform .
     • Если у вас есть резервирование с minCpuPlatform , и вы хотите создать экземпляр, который использует это резервирование, создать экземпляр с соответствующими свойствами, включая соответствующую minCpuPlatform .
   • localSsds.diskSizeGb
   • локальныйSsds.interface

2. Создайте экземпляр, соответствующий этим свойствам.

3. Опишите экземпляр, чтобы убедиться, что его свойства соответствуют резервированию.Например, с инструментом gcloud используйте экземпляров описывают команда.

4. Опишите свое бронирование, чтобы проверить что его inUseCount увеличилось.

   • Если inUseCount не изменилось, свойства не совпадают.
   • Если inUseCount увеличился, ваше резервирование используется.

Таргетинг на конкретное резервирование

Если вы попытаетесь создать экземпляр, нацеленный на конкретное резервирование, экземпляр не может быть создан, если он не соответствует свойствам резервирования.Использовать этот метод, чтобы убедиться, что у вас есть правильные свойства экземпляра.

1. Создать бронирование с вариант , требуемый для резервирования, .
2. Создайте экземпляр, который явно соответствует свойства экземпляра резервирования и что нацеливается на бронирование по имени через свойство сродства резервирования.
   • Если свойства экземпляра не совпадают, вы увидите ошибку.
   • Если свойства экземпляра совпадают, используется ваше резервирование.

Список и описание бронирования

Список и просмотр сведений о бронировании с помощью консоли, gcloud или API.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• compute.reservations.list в проекте, который нужно перечислить бронирование
• compute.reservations.get на проект или на оговорка, чтобы описать оговорку
Консоль

1. В облачной консоли перейдите к Скидки за обязательное использование страница.

   Перейти на скидки за обязательное использование

2. Щелкните Резервирование .

Список бронирований включает подробную информацию о каждом бронировании. Ты можешь используйте столбец Используемые машины (всего) для определения использования каждое бронирование.

gcloud

Зарегистрируйте свои бронирования в список бронирования gcloud compute команда:

Список резервирований вычислений gcloud [--filter = "zone :( ' ZONE ')"]

NAME IN_USE_COUNT COUNT ZONE
Бронирование-04 25 50 us-central1-a
Бронирование-05 0100 us-central1-b
 

Опишите свои бронирования с помощью gcloud compute reservations описывают команда:

Резервирование вычислений gcloud описывает  RESERVATION_NAME  --zone =  ZONE 

вид: вычислить # резервирование
название: оговорка-05
selfLink: https: // вычислить.googleapis.com/compute/v1/projects/my-project/zones/us-east1-d/reservations/reservation-05
конкретное бронирование:
  количество: '50'
  inUseCount: '25'
  instanceProperties:
    guestAccelerators:
    - ускорительКоличество: 1
      Тип ускорителя: nvidia-tesla-k80
    localSsds:
    - diskSizeGb: '375'
      интерфейс: SCSI
    Тип машины: n1-standard-2
    minCpuPlatform: любая платформа ЦП
specificReservationRequired: false
статус: ГОТОВ
зона: https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-east1-d 

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

Чтобы создать экземпляр, который использует это резервирование, не забудьте сопоставить свойства экземпляра бронирования. Например:

 экземпляров gcloud compute create my-instance \
    --accelerator = type = nvidia-tesla-k80, count = 1 \
    --main Maintenance-policy terminate \
    --local-ssd = interface = SCSI \
    - машинный тип п1-эталон-2 \
    --zone us-east1-d 

API

В API укажите свои бронирования, отправив запрос GET в бронирований.список метод.

  ПОЛУЧИТЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / reservations
  

Опишите бронирование, позвонив в reservations.get метод.

 ПОЛУЧИТЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / reservations /  RESERVATION_NAME 

{
  "id": "2533514314332214789",
  "creationTimestamp": "2019-09-27T08: 21: 14.707-07: 00",
  "selfLink": "https: // www.googleapis.com/compute/v1/projects/my-project/zones/us-east1-d/reservations/reservation-05 ",
  "зона": "https://www.googleapis.com/compute/v1/projects/my-project/zones/us-east1-d",
  "имя": "бронь-05",
  "specificReservationRequired": ложь,
  «статус»: «ГОТОВ»,
  "kind": "вычислить # резервирование",
  "specificReservation": {
    "instanceProperties": {
      "machineType": "n1-стандарт-2",
      "guestAccelerators": [
        {
          "acceleratorType": "nvidia-tesla-k80",
          "acceleratorCount": 1
        }
      ],
      "minCpuPlatform": "Любая платформа ЦП",
      "localSsds": [
        {
          "diskSizeGb": "375",
          «интерфейс»: «SCSI»
        }
      ]
    },
    "count": "50",
    "inUseCount": "25"
  }
} 

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

Изменение бронирования

Вы можете изменить размер или удалить бронирование, если оно не прикреплено к обязательство.

Изменение размера резервирования

Вы можете изменить размер количества виртуальных машин в резервировании, которые не привязаны к обязательство с помощью инструмента gcloud или API.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• вычисл.reservations.resize по резервации

gcloud

Измените размер бронирования с помощью gcloud compute reservations update команда. Например:

Создайте резервирование для двух экземпляров ВМ:

gcloud compute reservations создать резервирование-01 \
    --machine-type = n2-standard-32 \
    --zone = us-central1-a \
    --vm-count = 2
 

Измените размер резервирования с двух до десяти экземпляров ВМ:

gcloud compute reservations обновить резервирование-01 \
    --zone = us-central1-a \
    --vm-count = 10
 

API

В API создайте запрос POST к бронирований.изменить размер метод и включите новый specificSkuCount в тело запроса. Следующее тело запроса обновляет количество виртуальных машин резервирования до 10 .

  POST https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / reservations /  RESERVATION_NAME  / resize

{"specificSkuCount": "10"}
  

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

Удаление бронирования

Вы можете удалить бронирования, которые не связаны с обязательством, с помощью консоль, инструмент gcloud или API.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• compute.reservations.delete на резервирование
Консоль

1. В облачной консоли перейдите к Скидки за обязательное использование страница.

   Перейти на скидки за обязательное использование

2. Щелкните Бронирование , чтобы просмотреть список ваших бронирований.

3. Установите флажок рядом с каждым резервированием, которое вы хотите удалить.

   Примечание: Если резервирование имеет родительское обязательство, его нельзя удалить.

4. Щелкните Удалить резерв .

gcloud

Вы можете отменить резервирование с помощью удалить команду :

  gcloud compute reservations удалить  RESERVATION_NAME  --zone  ZONE 
  

API

В API создайте запрос DELETE к бронирование.удалить метод.

  УДАЛИТЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / reservations /  RESERVATION_NAME 
  

После успешного завершения команды удаления с вас больше не взимается плата. для резервирования, и ресурсы больше не зарезервированы для ты. Удаление резервирования не влияет ни на какие запущенные экземпляры, которые были привязан к этой оговорке; с вас по-прежнему взимается плата за эти экземпляры.

Объединение бронирований со скидками за обязательное использование

Скидка за обязательное использование предоставляет договор со скидкой на 1 или 3 года, но не оставляет емкость в определенной зоне. Резервирование гарантирует, что емкость удерживается в определенная зона, даже если зарезервированные виртуальные машины не работают. Объединив При бронировании с обязательством вы можете получить зарезервированные ресурсы со скидкой.

По умолчанию, когда вы создаете резервирование, любое применимое подтвержденное использование Скидки на ядра и память автоматически применяются к вашим экземплярам ВМ.Однако, чтобы получить обязательные скидки на использование графических процессоров и локальных твердотельных накопителей, вы должны создайте резервирование этих ресурсов при покупке обязательства.

После того, как вы приобрели обязательство, вы не можете его отменить. Для большего информацию см. Обязательные скидки на использование.

Обязательство по приобретению графических процессоров или локальных твердотельных накопителей

Примечание: Следующие шаги объясняют, как приобрести обязательства для графических процессоров, которые используют универсальный тип машины Н1. Обязательства по приобретению графических процессоров NVIDIA A100, которые тесно связаны с Типы машин A2, следуйте инструкциям для Обязательства по закупке типов машин.

Чтобы приобрести обязательство для графических процессоров или локальных твердотельных накопителей:

• Вы должны приобрести обязательство общего назначения N1. Поддерживаются только графические процессоры с типами компьютеров N1 (за исключением графических процессоров A100).
• Вы должны создать бронирование который включает в себя либо графические процессоры, либо локальные твердотельные накопители одновременно, когда вы покупка вашего обязательства.
• Вам не нужно фиксировать виртуальные ЦП или память.

Вы должны приобрести обязательства для определенных типов графических процессоров. Например, вы можете приобретите NVIDIA P100 или NVIDIA V100, но вы не можете покупать обязательства для графических процессоров NVIDIA P100 и ожидайте применения их к другим типам графических процессоров.

Количество зарезервированных вами графических процессоров и локальных твердотельных накопителей должно быть равно количеству что вы обязуетесь. Например, если вы хотите зарезервировать 4 графических процессора V100, вы также необходимо использовать 4 графических процессора V100. Однако количество виртуальных ЦП и памяти, которые вы резерв может быть больше или меньше того, что вы обязуетесь.

Если вы хотите выполнить фиксацию только для графических процессоров или локальных SSD, вы можете указать 0 для vCPU и обязательства по памяти. Но оговорка, которую вы прилагаете к своему обязательству должны содержать те же графические процессоры и локальные твердотельные накопители, что и обязательство, а также типы машин (с виртуальными ЦП и памятью), которые вы хотите зарезервировать.

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

Купить обязательство с прикрепленным резервированием, используя Облачная консоль, инструмент gcloud или API.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• вычисл.commitments.create , чтобы создать обязательство для виртуальной машины.
• compute.commitments.list , чтобы просмотреть список обязательств по проекту.
• compute.commitments.updateReservations для создания резервирования для графических процессоров или SSD.
Консоль

1. В консоли Google Cloud перейдите на страницу Обязательные скидки на использование .

   Перейти на скидки за обязательное использование

2. Чтобы приобрести новое обязательство, щелкните Обязательство покупки .

3. Назовите свое обязательство и выберите регион, в котором вы хотите его применить.

4. Для Вид обязательства выберите Общего назначения .

5. Выберите обязательство Срок действия 1 или 3 года.

6. Введите количество ядер и памяти , которое вы хотите приобрести. Если вы хотите только зафиксировать и зарезервировать графические процессоры или локальные твердотельные накопители без фиксируя виртуальные ЦП и память, укажите 0 для виртуальных ЦП и памяти объемы обязательств.

7. Щелкните Добавить графические процессоры и выберите тип графического процессора и Количество графических процессоров что вы хотите сделать.

8. Щелкните Добавить локальный SSD и укажите количество дисков, которое вы хотите совершить.

9. Щелкните Добавить новое резервирование , чтобы создать одно или несколько резервирований для экземпляры, которые будут использовать графические процессоры и локальные твердотельные накопители.

   1. Укажите название вашего бронирования.
   2. Меньше Используйте с экземпляром ВМ :
      • Если вы хотите использовать ресурсы этого резервирования только при создании совпадающие экземпляры, которые специально нацелены на это резервирование имя, выберите Выберите конкретное бронирование .
      • Если вы хотите, чтобы совпадающие экземпляры автоматически использовали это резервирование, выберите Использовать резервирование автоматически .
   3. Выберите Зону , в которой вы хотите зарезервировать ресурсы.
   4. Укажите Число экземпляров ВМ, которые вы хотите зарезервировать.
   5. Укажите ресурсы, которые вы хотите зарезервировать для каждого экземпляра:
      • Если у вас есть шаблон экземпляра, щелкните Использовать шаблон экземпляра и выберите шаблон экземпляра из списка.
      • В противном случае нажмите Укажите тип машины .
        1. Щелкните Настроить , чтобы использовать ползунок для выбора Ядра и Память для вашего типа машины.
        2. Укажите платформу ЦП .
        3. Чтобы добавить графические процессоры, введите количество графических процессоров и графических процессоров типа .
        4. При желании укажите количество локальных SSD , которые вы хотите добавить к каждому экземпляру и указать интерфейс введите для использования.
   6. Нажмите кнопку Готово , чтобы создать резервирование.
   Примечание: Количество зарезервированных вами графических процессоров и локальных твердотельных накопителей. должен быть равен сумме, которую вы обязуетесь.

10. Нажмите кнопку Купить , чтобы приобрести обязательство.

11. Прочитать условия покупки и нажмите Купить , когда будете готовы приобрести обязательство.

gcloud

Используйте команду gcloud compute commmitments create приобрести обязательство и включить флажки для создания прикрепленного бронирование.

Например, следующее обязательство включает 4 графических процессора и новое резервирование для этих 4 графических процессоров, которые будут использоваться в 2 экземплярах n1-standard-32 в us-central1-a .

Обязательства gcloud compute создают обязательство-01 \
    --region = us-central1 \
    --resources = vcpu = 96, память = 624 ГБ \
    --resources-accelerator = type = nvidia-tesla-v100, count = 4 \
    --план 12-месячный \
      --reservation = резервирование-01 \
    --reservation-zone = us-central1-a \
    --machine-type = n1-standard-16 \
    --accelerator = type = nvidia-tesla-v100, count = 2 \
    --vm-count = 2 
 

Если вы хотите зафиксировать и зарезервировать графические процессоры или локальные твердотельные накопители без фиксации для виртуальных ЦП и памяти укажите 0 для виртуальных ЦП и выделения памяти количества.

Обязательства gcloud compute создают обязательство-01 \
    --region = us-west2 \
      --resources = vcpu = 0, memory = 0  \
    --resources-accelerator = type = nvidia-tesla-p4, count = 1 \
    --план 12-месячный \
    --reservation = резервирование-01 \
    --reservation-zone = us-west2-b \
    --machine-type = n1-standard-2 \
    --accelerator = type = nvidia-tesla-p4, count = 1 \
    --vm-count = 1
 

Чтобы создать несколько резервирований при покупке обязательства, используйте YAML файл, содержащий свойства резервирования.Например:

Обязательства gcloud compute создают обязательство-01 \
    --region = us-central1 \
    --resources = vcpu = 96, memory = 624, local-ssd = 750 \
    --resources-accelerator = type = nvidia-tesla-v100, count = 1 \
    --план 12-месячный \
      --reservations-from-file =  YAML_FILE  
 

Например, следующий файл YAML содержит 2 резервирования. Первое резервирование, res-01 , содержит экземпляр 1 n1-standard-2 с 1 графическим процессором и это целевое резервирование, а это значит, что вы должны специально настроить таргетинг это резервирование по имени для использования зарезервированных экземпляров.Второй резервирование, res-02 , содержит 1 n1-standard-2 экземпляр ВМ с двумя типами подключенных локальных SSD.

&дефис; бронирование: res-01
  Зона_резервации: us-central1-a
  require_specific_reservation: истина
  vm_count: 1
  machine_type: n1-стандарт-2
  ускоритель:
  &дефис; количество: 1
    тип: nvidia-tesla-v100
&дефис; бронирование: res-02
  Зона_резервации: us-central1-a
  vm_count: 1
  machine_type: n1-стандарт-2
  local_ssd:
  &дефис; интерфейс: scsi
    размер: 375
  &дефис; интерфейс: nvme
    размер: 375
 

API

Используйте обязательства региона .вставить метод и включите поле reservations , чтобы определить характеристики. Например, следующее обязательство включает 4 графических процессора и резервирование для этих 4 графических процессоров, которые будут использоваться в 2 экземплярах в us-central1-a .

 ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / регионы /  РЕГИОН  / обязательства

{
  "имя": "обязательство-01",
  "план": "TWELVE_MONTH",
  "Ресурсы":
  [
    {
      "amount": "96",
      "тип": "VCPU"
    },
    {
      "amount": "638976",
      "тип": "ПАМЯТЬ"
    },
    {
      "acceleratorType": "nvidia-tesla-v100",
      "amount": "4",
      "тип": "УСКОРИТЕЛЬ"
    }
  ],
  "оговорки":
  [
    {
      "имя": "бронь-01",
      "specificReservation":
      {
        "count": "2",
        "instanceProperties":
        {
          "guestAccelerators":
          [
            {
              "acceleratorCount": 2,
              "acceleratorType": "nvidia-tesla-v100"
            }
          ],
          "machineType": "n1-standard-8"
        }
      },
      "specificReservationRequired": ложь,
      "зона": "us-central1-a"
    }
  ]
} 

Если вы хотите зафиксировать и зарезервировать только графические процессоры или локальные твердотельные накопители без фиксируя виртуальные ЦП и память, укажите 0 для виртуальных ЦП и памяти объемы обязательств.Например:

 ЗАПИСЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / регионы /  РЕГИОН  / обязательства

{
  "имя": "обязательство-01",
  "план": "TWELVE_MONTH",
  "Ресурсы":
  [
  {
      "amount": "0",
      "тип": "VCPU"
    },
    {
      "amount": "0",
      "тип": "ПАМЯТЬ"
    }, 
    {
      "acceleratorType": "nvidia-tesla-v100",
      "amount": "4",
      "тип": "УСКОРИТЕЛЬ"
    }
  ],
  "оговорки":
  [
    {
      "имя": "бронь-01",
      "specificReservation":
      {
        "count": "2",
        "instanceProperties":
        {
          "guestAccelerators":
          [
            {
              "acceleratorCount": 2,
              "acceleratorType": "nvidia-tesla-v100"
            }
          ],
          "machineType": "n1-standard-8"
        }
      },
      "specificReservationRequired": ложь,
      "зона": "us-central1-a"
    }
  ]
} 

Обязательство успешно создано только при наличии достаточных ресурсов. в целевой зоне и достаточной квоты на момент запроса.

Когда вы создаете обязательство с прикрепленным резервированием, вы не можете удалить резервирование на время действия обязательства. Когда ваше обязательство истечет, Compute Engine автоматически удаляет все прикрепленные бронирования.

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

Изменение оговорок, связанных с обязательствами

Если у обязательства есть одно или несколько резервирований с графическими процессорами или местными SSD, вы можете использовать инструмент gcloud или API для передачи графических процессоров или локальные SSD в этих резервациях.Например, вы можете переместить графические процессоры из одно бронирование на второе, новое бронирование.

Ограничения:

gcloud

Используйте бета-версию gcloud. Обязательства по вычислениям update-reservations команда.

Создайте обязательство с одним резервированием:

• res-1 имеет 4 n1-standard-2 экземпляров, каждый с 1 графический процессор P100 (4 виртуальных ЦП и 4 графических процессора P100). Общие зарезервированные ресурсы включают 4 графических процессора P100.

Обязательства по вычислениям бета-версии gcloud создают мои-обязательства-с-резервированием \
    --region = asia-east1 \
    --resources = vcpu = 10, память = 32 ГБ \
    --resources-accelerator = type = nvidia-tesla-p100, count = 4 \
    --план 12-месячный \
    --reservations-from-file = одно-резервирование.ямл
 

Файл one -servations.yaml содержит:

  - бронирование: рес-1
  зона_резервации: азия-восток1-а
  require_specific_reservation: истина
  vm_count: 4
  machine_type: n1-стандарт-2
  ускоритель:
  - количество: 1
    тип: nvidia-tesla-p100
  

Обновите обязательство по переносу некоторых ресурсов с res-1 на новый, второе бронирование, рес-2 . В этом примере:

• Измените res-1 , чтобы получить 2 экземпляра n1-standard-2 , каждый с 2 графических процессора P100 (2 виртуальных ЦП и 2 графических процессора P100).
• Добавьте res-2 , чтобы получить 2 экземпляров n1-standard-2 каждый с 1 графический процессор P100 (4 виртуальных ЦП и 2 графических процессора P100).

Общее количество зарезервированных графических процессоров в рамках обязательства остается постоянным и составляет 4.

Обязательства по бета-вычислениям gcloud, обновление-резервирование, мое-обязательство-с-резервированием \
    --region = us-central1 \
    --reservations-from-file = two-reservations.yaml
 

Файл two-reservations.yaml содержит:

  - бронирование: рес-1
  зона_резервации: азия-восток1-а
  require_specific_reservation: истина
  vm_count: 2
  machine_type: n1-стандарт-2
  ускоритель:
  - количество: 1
    тип: nvidia-tesla-p100
- бронирование: рес-2
  зона_резервации: азия-восток1-а
  require_specific_reservation: истина
  vm_count: 2
  machine_type: n1-стандарт-2
  ускоритель:
  - количество: 1
    тип: nvidia-tesla-p100
  

API

Используйте обязательства региона .обновить бронирование метод.

Например, создайте обязательство со следующим резервированием:

• res-1 имеет 4 n1-standard-2 экземпляров каждый с 1 nvidia-tesla-p100 графический процессор (4 виртуальных ЦП и 4 графических процессора P100).

В этом примере общие зарезервированные ресурсы включают 4 графических процессора P100.

POST https://compute.googleapis.com/compute/beta/projects/my-project/regions/asia-east1/commitments/my-commitment-with-reservation/updateReservations

{
  "name": "мое обязательство с бронированием",
  "план": "TWELVE_MONTH",
  "оговорки":
  [
    {
      "name": "res-1",
      "specificReservation":
      {
        "count": "4",
        "instanceProperties":
        {
          "guestAccelerators":
          [
            {
              "acceleratorCount": 1,
              "acceleratorType": "nvidia-tesla-p100"
            }
          ],
          "machineType": "n1-стандарт-2"
        }
      },
      "specificReservationRequired": true,
      "зона": "азия-восток1-а"
    }
  ],
  "Ресурсы":
  [
    {
      "amount": "10",
      "тип": "VCPU"
    },
    {
      "amount": "32768",
      "тип": "ПАМЯТЬ"
    },
    {
      "acceleratorType": "nvidia-tesla-p100",
      "amount": "4",
      "тип": "УСКОРИТЕЛЬ"
    }
  ]
}
 

Обновите обязательство по переносу некоторых ресурсов с res-1 на новый, второе бронирование, рес-2 .В этом примере:

• Измените res-1 , чтобы получить 2 экземпляра n1-standard-2 , каждый с 2 графических процессора P100 (2 виртуальных ЦП и 2 графических процессора P100).
• Добавьте res-2 , чтобы получить 2 экземпляров n1-standard-2 каждый с 1 графический процессор P100 (4 виртуальных ЦП и 2 графических процессора P100).

Общее количество зарезервированных графических процессоров в рамках обязательства остается постоянным и составляет 4.

POST https://compute.googleapis.com/compute/beta/projects/my-project/regions/asia-east1/commitments/my-commitment-with-reservation/updateReservations

{
  "оговорки":
  [
    {
      "name": "res-1",
      "specificReservation":
      {
        "count": "2",
        "instanceProperties":
        {
          "guestAccelerators":
          [
            {
              "acceleratorCount": 1,
              "acceleratorType": "nvidia-tesla-p100"
            }
          ],
          "machineType": "n1-стандарт-2"
        }
      },
      "specificReservationRequired": true,
      "зона": "азия-восток1-а"
    },
    {
      "name": "res-2",
      "specificReservation":
      {
        "count": "2",
        "instanceProperties":
        {
          "guestAccelerators":
          [
            {
              "acceleratorCount": 1,
              "acceleratorType": "nvidia-tesla-p100"
            }
          ],
          "machineType": "n1-стандарт-2"
        }
      },
      "specificReservationRequired": true,
      "зона": "азия-восток1-а"
    }
  ]
}
 

Просмотр отчетов об использовании резервирования

Экспорт подробных отчетов об использовании Compute Engine в облачное хранилище ведро, используя функцию экспорта использования.Видеть Просмотр отчетов об использовании для получения инструкций.

В отчете об использовании указано:

• Зарезервированные ресурсы, которые используются. Эти записи отображаются как обычные виртуальные ЦП, память, графический процессор и локальные ресурсы SSD.
• Зарезервированные ресурсы, которые не используются. Эти записи имеют обычные названия SKU. и URI ресурсов резервирования.
• Всего зарезервированных ресурсов. Эти записи имеют названия артикулов резервирования и URI ресурсов резервирования. С этими записями не связано никаких затрат. Используйте эти записи, чтобы подсчитать, какую часть ваших бронирований вы используете.

Измерение	MeasurementId формат	Формат URI ресурса
Зарезервированные ресурсы, которые используются	com.google.cloud/services/compute-engine/ SKU_NAME	https://compute.googleapis.com/compute/v1/projects/ PROJECT_ID / zone / ZONE / RESOURCE_TYPE / RESOURCE_NAME . Например, https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances/my-instance
Зарезервированные ресурсы, которые не используются	com.google.cloud/services/compute-engine/ SKU_NAME	https://compute.googleapis.com/compute/v1/projects/ PROJECT_ID / Zone / ЗОНА / reservations / RESERVATION_NAME . Например, https://compute.googleapis.com/compute/v1/projects/my-project/zones/europe-west1-a/reservations/my-reservation
Всего зарезервированных ресурсов	com.google.cloud/services/compute-engine/Reservation SKU_NAME	https://compute.googleapis.com/compute/v1/projects/ PROJECT_ID / Zone / ЗОНА / reservations / RESERVATION_NAME . Например, https://compute.googleapis.com/compute/v1/projects/my-project/zones/europe-west1-a/reservations/my-reservation

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

• В строке 1 показано зарезервированное ОЗУ, которое используется в настоящее время. ResourceId строки показывает, что эта RAM используется экземпляром с именем my-instance .
• В строке 2 показано зарезервированное ОЗУ, которое не используется. ResourceId строки показывает, что это зарезервированное ОЗУ содержится в my-reserve ; он еще не используется ни одним пример.
• Строка 3 показывает общую зарезервированную RAM.

Дата отчета, MeasurementId, Quantity, Unit, Resource URI, ResourceId, Location
2019-06-06, com.google.cloud / services / compute-engine / VmimageN2StandardRam, 166970074857472, байт-секунды, https: //compute.googleapis.com/compute/v1/projects/my-project/zones/us- central2-a / instance / my-instance, 1775485842510981624, us-central2-a
2019-06-06, ком.google.cloud/services/compute-engine/VmimageN2StandardRam,166970074857472,byte-seconds,https://compute.googleapis.com/compute/v1/projects/my-project/zones/us-central2-a/reservations/my- бронирование, 7.58809E + 17, us-central2-a
2019-06-06, com.google.cloud / services / compute-engine / ReservationN2StandardRam, 333
9714944, байт-секунды, https: //compute.googleapis.com/compute/v1/projects/my-project/zones/us- central2-a / reservations / my-booking, 7.58809E + 17, us-central2-a
...
 

Биллинг с резервированием

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

Возьмем следующий пример:

• У вас есть обязательство по 3 виртуальным ЦП в us-central1
• Вы используете 5 виртуальных ЦП в us-central1-a
• У вас зарезервировано 10 виртуальных ЦП в us-central1-a

Вам будет выставлен счет:

Покрывается	# виртуальных ЦП
Цена со скидкой для обязательства по использованию	3
Цена по запросу (2 использованных виртуальных ЦП резервирования + 5 неиспользованных резервирований виртуальных ЦП)	7

Что дальше

Как продолжают подавлять голосование коренных американцев

Несмотря на принятие Закона о гражданстве индейцев 1924 года, многие коренные американцы, живущие в резервациях, по-прежнему не участвовали в демократическом процессе.В 1948 году коренные американцы в Нью-Мексико и Аризоне успешно оспорили свое право голоса. Юта и Северная Дакота стали последними штатами, которые предоставили коренным американцам в резервациях право голоса в 1957 и 1958 годах соответственно. Когда право голоса было наконец обеспечено, законы о подавлении избирателей не позволили коренным американцам голосовать и баллотироваться на выборные должности. В Аризоне, например, коренные американцы не могли полноценно участвовать в голосовании до 1970 года, когда Верховный суд оставил в силе запрет на использование тестов на грамотность ( Oregon v.Mitchell , 400 U.S. 112 (1970)). Сегодня право голоса по-прежнему оспаривается посредством принятия новых законов и практик, которые либо не учитывают, не игнорируют, либо преднамеренно нацелены на избирателей из числа коренных американцев.

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

Я никогда не забуду бабушку навахо, которая говорила только на навахо и не могла голосовать после того, как Аризона приняла закон об удостоверениях личности избирателя в 2004 году.Она несколько раз пыталась самостоятельно получить удостоверение личности в Аризоне, но ей отказали, поскольку она родилась в доме в хогане, а школы-интернаты изменили ее имя навахо на английское. Она жила в скромном доме в резервации навахо без электричества и водопровода и вела традиционный образ жизни, заботясь о своих овцах. Она была смущена и опустошена, когда ее не допустили к участию в выборах из-за отсутствия удостоверения личности. Работая с ней, команда из Indian Legal Clinic проехала пять часов, чтобы встретиться с ней в офисах нескольких агентств и получить ее отложенное свидетельство о рождении; затем мы пошли в два отдельных офиса автомобильного отдела.Первый не выдал удостоверения личности с фотографией в тот же день, а другой изначально отклонил ее запрос. Офис отклонил ее просроченное свидетельство о рождении навахо, пока я не смог вмешаться и продемонстрировать им, что это был приемлемый документ. Система не смогла принять во внимание ее реальность как женщину навахо и не оценила ее как избирателя. К счастью, она настойчиво использовала свое право голоса, но не все избиратели им и не должны были быть такими.

Этот пример помогает объяснить, почему голосование может быть трудным для избирателей из числа коренных американцев.Явка коренных американцев самая низкая в стране по сравнению с другими группами. Хотя ряд проблем способствует низкой явке избирателей, исследование, проведенное Коалицией за права голоса коренных американцев, показало, что низкий уровень доверия к правительству, отсутствие информации о том, как и где регистрироваться и голосовать, большие расстояния для регистрации и к голосованию, низкий уровень доступа к Интернету, враждебность по отношению к коренным американцам и запугивание являются препятствиями. Условия изоляции, такие как языковые барьеры, социально-экономическое неравенство, отсутствие доступа к транспорту, отсутствие адресов проживания, отсутствие доступа к почте и цифровой разрыв ограничивают участие коренных американцев в политической жизни.Изменения в процессах голосования еще больше подрывают способность коренных американцев голосовать.

В рамках своей социально-экономической реальности коренные американцы сталкиваются с препятствиями при выборе кормления своих семей или расходования ресурсов, которые могут повлиять на их право голоса. Это может включать в себя продление их P.O. поле, заменяя идентификатор для обновления адреса проживания, или проезжая значительное расстояние, чтобы зарегистрироваться для голосования или голосования. В национальном масштабе уровень бедности коренных американцев составляет 26 человек.8 процентов. Коренные американцы с большей вероятностью будут работать на нескольких работах, у них нет надежного транспорта и адекватных ресурсов по уходу за детьми, что делает голосование прагматично трудным.

Дополнительной проблемой, затрагивающей многих коренных американцев, является бездомность или почти бездомность из-за крайней бедности и отсутствия доступного жилья во многих резервациях. Исследование, проведенное Департаментом жилищного строительства и городского развития, показало, что от 42 000 до 85 000 человек в районах проживания племен занимаются серфингом на диване и останавливаются у друзей или родственников только потому, что им негде жить.Отсутствие постоянного жилья влияет на способность этих членов племени иметь постоянный физический адрес, но это не должно препятствовать их возможности реализовать свое право голоса.

Законы о нетрадиционных адресах, регистрации избирателей и удостоверениях личности

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

В то время как 84 процента U.Население S. живет в городских районах, многие коренные американцы и коренные жители Аляски живут в сельских общинах, в которых нет адресов проживания. Дома обычно описываются с точки зрения ориентиров, перекрестков и направлений. Многие дороги в резервациях - это неулучшенные грунтовые или гравийные дороги плохого качества и часто безымянные. После штормов многие дороги становятся непроходимыми. Из-за этих плохих условий Почтовая служба США не доставляет почту большинству жителей резервации на дом.

Из-за отсутствия адресов проживания большинство жителей полагаются на P.О. ящики в соседнем городе или получать почту через торговый пост или другое место. Некоторым резидентам резервации приходится преодолевать расстояние до 70 миль в одном направлении, чтобы получить почту. В Аризоне, например, только 18 процентов избирателей в резервациях за пределами округов Марикопа и Пима имеют адреса проживания и получают почту дома. Нация навахо, самая большая резервация в Соединенных Штатах - больше, чем Западная Вирджиния, - не имеет программы адресации, и большинство людей живут в отдаленных общинах.Точно так же во многих других бронированиях отсутствует доставка почты на дом. В резервации Тохоно О'одхам зарегистрировано 1900 человек. ящики и несколько почтовых ящиков кластера. Жители могут проверять свою почту каждые две недели, а некоторые только раз в месяц.

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

Хотя многие американцы могут зарегистрироваться для голосования одним нажатием кнопки, не выходя из дома, это не относится к резидентам резервации. Для зарегистрированных избирателей существует мало возможностей зарегистрировать или обновить свою регистрацию избирателей из-за расположения служб регистрации избирателей, отсутствия адресов проживания и отсутствия широкополосной связи. Менее половины домов на землях племен имеют надежный широкополосный доступ. Даже если у избирателя есть доступ к широкополосной связи при бронировании, большинство систем онлайн-регистрации избирателей требуют удостоверение личности штата для регистрации для голосования и не принимают удостоверения личности племени.В Аризоне, например, для онлайн-регистрации физическое лицо должно иметь удостоверение личности штата и адрес проживания, зарегистрированные в Департаменте транспортных средств, что исключает эту возможность для большинства жителей резервации.

Зарегистрироваться для голосования онлайн или поехать куда-нибудь, чтобы зарегистрироваться для голосования, или проголосовать само по себе, может быть сложно с материально-технической точки зрения, если не экономически невыполнимо. Например, в Аризоне отсутствие адресов проживания привело к тому, что зарегистрированным избирателям отказывали в удостоверениях личности на избирательных участках или включали в список ожидания, что означает, что избиратель не помещается на избирательный участок.Хотя окружные офисы могут предлагать личную регистрацию избирателей в обычные рабочие часы, это может быть сложной задачей для избирателей из числа коренных американцев, которые могут проживать в 100 милях или более от округа. Кроме того, для некоторых коренных американцев и коренных жителей Аляски необходимо предоставить устный перевод для регистрации избирателей и голосования.

Закон

об удостоверениях личности избирателя еще больше усложняет эту проблему. Коренные американцы с меньшей вероятностью будут иметь форму удостоверения личности, соответствующую законам об удостоверении личности избирателей, требующим адреса проживания, потому что помимо штатов, не учитывающих племенные удостоверения личности при принятии этих законов, существуют также социально-экономические и институциональные факторы, которые не позволяют жителям резервации получить удостоверения личности.Хотя многие племена выдают удостоверения личности, не все племенные удостоверения включают адреса. Даже если у члена племени есть удостоверение личности с адресом, поскольку избиратели резервации не имеют адреса проживания, на удостоверении личности может быть указан P.O. поле или описательный адрес. Нетрадиционные адреса не вписываются в системы баз данных округов, в результате округа повторно назначают адреса избирателям. Это может привести к тому, что идентификатор будет отклонен из-за недостаточной подготовки сотрудников опроса или из-за того, что он не совпадает с адресом проживания в файле избирателя.Это привело к тому, что избирателям было отказано в регулярном голосовании, потому что адреса в их удостоверениях личности не совпадали с адресами, назначенными округами для базы данных регистрации избирателей.

Закон об удостоверении личности избирателя, требующий адреса проживания, вступил в силу в Северной Дакоте прямо перед промежуточными выборами 2018 года, который прямо исключил использование P.O. ящики как адреса проживания. Более 5000 коренных американцев не имели необходимого удостоверения личности для голосования, поскольку ни в одном бронировании не было адреса проживания.Племена искали решения до дня выборов. Государственный секретарь Северной Дакоты сообщил вождям племен, что избиратели могут позвонить координатору службы 911 округа, чтобы узнать адрес. Это было скудное решение, учитывая, что большинство племенных резерваций охватывает несколько юрисдикций, создавая противоречия и путаницу для племен. В округе Су, где расположено племя сиу Стэндинг Рок, координатором службы экстренной помощи является шериф округа, что является сдерживающим фактором для членов сообщества, опасающихся правоохранительных органов.Когда член племени сиу Стандинг Рок позвонил, чтобы узнать адрес ее проживания, шериф сказал ей, что перевозит заключенных и не может назначить адреса в тот день. Другому избирателю был назначен адрес проживания, соответствующий соседнему бару, что подвергало этого члена племени мошенничеству, если он голосовал по этому адресу.

В результате племенам Северной Дакоты пришлось разработать планы действий в чрезвычайных ситуациях, чтобы предоставить своим членам адреса проживания и соответствующие идентификаторы. Они оставили свои офисы открытыми в течение продленных часов и начали бесплатно выдавать удостоверения личности членам племени, вплоть до того, что идентификационная машина группы Turtle Mountain Band Чиппевы перегрелась.Хотя государственный секретарь никогда прямо не одобрял план племен, у племен не было других вариантов, и им пришлось предпринять чрезвычайные усилия, чтобы гарантировать, что члены их племен могут голосовать.

В то время как племена предпринимали действия по выдаче бесплатных идентификаторов племени, отвечающих новым требованиям, они тратили ресурсы, которых у них не было, на помощь членам своего племени. У членов племен в Северной Дакоте высокий уровень безработицы и бедности. В Spirit Lake почти 50 процентов членов племени живут за чертой бедности; а в Черепашьей горе уровень безработицы составляет почти 70 процентов.Избиратели из числа коренных американцев, проживающие в резервациях, имеют такое же конституционное право голоса, как и любой другой гражданин. В этом случае племенные правительства должны были расходовать свои собственные ресурсы, чтобы обеспечить членам племен возможность голосовать на выборах штата и федеральных выборах.

Доступ к участкам для личного голосования и движение по почте

Если избиратель из числа коренных американцев или коренных жителей Аляски, проживающий в сельской местности, преодолевает неотъемлемые барьеры, связанные с нестандартными адресами, барьерами регистрации избирателей, и ему удается получить правильное удостоверение личности, избиратель может быть дополнительно обременен системой голосования по почте или отсутствие свободных избирательных участков.Голосование по почте часто ненадежно и не так доступно для коренных американцев, живущих в резервациях, как для избирателей вне резерваций. Избиратели из числа коренных американцев реже получают почту в свои дома, особенно если они живут на племенных землях. Многие избиратели, проживающие в резервациях, живут в сельской местности, где почта обычно приходит поздно или вообще не приходит. У неиспаноязычных белых на 350 процентов больше шансов получить почту домой, чем у коренных американцев в Аризоне. Трудности с доступом к почте затрудняют голосование по почте, потому что поездка в P.О. ящик, чтобы забрать свой бюллетень и затем вернуть его, может быть делом на целый день; без машины это может быть невозможно. Аналогичные опасения существуют и в отношении избирателей из числа коренного населения Аляски в сельских деревнях, которые полагаются на общий почтовый адрес. коробки, а иногда доставка почты может занять до трех недель из-за погодных условий. Кроме того, многие индейские языки являются устными; поэтому языковая помощь избирателям из числа коренных американцев требует личного перевода, который нельзя сделать по почте.

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

Следующие примеры иллюстрируют, как решения, принимаемые выборными должностными лицами, влияют на способность коренных избирателей участвовать в демократическом процессе.В 2008 году правительство Аляски упразднило избирательные участки в деревнях коренных жителей Аляски в рамках «перестановки округов», в результате которой избирателям пришлось лететь самолетом, чтобы проголосовать. В 2016 году племена Пайуте Пирамид-Лейк и Уокер-Ривер в Неваде подали иск перед всеобщими выборами 2016 года, чтобы получить избирательные участки в резервации. В 2016 году округ Сан-Хуан, штат Юта, перешел на систему голосования только по почте и предложил личное досрочное голосование только в части округа, где преобладает белое большинство; нация навахо подала в суд, чтобы обеспечить личное местонахождение и соблюдение требований языковой помощи в соответствии с разделом 203 Закона об избирательных правах.

Племя Кайбаб Пайуте в Аризоне избиратели должны были преодолеть 280 миль в одну сторону в 2016 и 2018 годах, чтобы проголосовать досрочно лично. Когда округ Пима закрыл досрочное голосование по резервации Паскуа Яки в 2018 году, избиратели Паскуа Яки сообщили, что для участия в досрочном голосовании с использованием общественного транспорта потребовалось более двух часов. Недавно закрытие избирательных участков в резервации Мандан Хидатса в Северной Дакоте привело к тому, что избирателям пришлось преодолевать 80–100 миль, чтобы проголосовать.Эти примеры демонстрируют, какие огромные расстояния должны преодолеть избиратели, и препятствия, которые им необходимо преодолеть, чтобы проголосовать. Преобладание этих барьеров подрывает нашу демократию и способствует низкому уровню участия коренных американцев в голосовании.

Закон об избирательных правах коренных американцев

Конгресс представил Закон об избирательных правах коренных американцев от 2019 года (H.R. 1694; S. 739), чтобы устранить барьеры для голосования и улучшить доступ к голосованию для избирателей коренных американцев и коренных жителей Аляски.Законодательство предоставит ресурсы и надзор для обеспечения того, чтобы коренные американцы имели равный доступ к процессу голосования. В соответствии с обязанностью доверительного управления законопроект потребует от Министерства юстиции ежегодно консультироваться с племенами по вопросам голосования. Ключевые элементы законопроекта включают улучшение доступа к участкам регистрации избирателей и избирательным участкам, одобрение использования племенных удостоверений личности для целей выборов и требование, чтобы юрисдикции консультировались с племенами перед закрытием регистрации избирателей или избирательных участков на индийских землях.В законопроекте прямо указано, что идентификационный номер племени не обязательно должен включать адрес проживания или дату истечения срока действия для целей голосования. Законопроект также предусматривает создание программы грантов Целевой группы по голосованию коренных американцев для обеспечения столь необходимого финансирования для работы с избирателями, образования, регистрации и явки в общинах коренных американцев.

Заключение

Закон, запрещающий право голоса, претендует на нейтральный характер; однако во многих случаях это подрывает самое основное право на участие в нашей демократии.Утрата права голоса - это потеря голоса в демократическом процессе. Мы должны делать больше для того, чтобы все американцы, включая коренных американцев, могли легко и с неуместными трудностями воспользоваться этим правом.

Почему резервации в Индии такие бедные? Взгляд на дно 1%

Когда клиенты, которые живут и работают в соседней резервации индейцев кроу, не платят за машину, Square One Finance of Billings, Montana мало что может сделать. Обращение в государственный суд с целью изъятия автомобиля или взыскания заработной платы - не вариант.Вместо этого Square One входит в темную сферу международных отношений. Оговорка - это отдельная нация - решения американских судов не подлежат исполнению. И шансы найти клиента и машину в обширной сельской резервации или выиграть в непредсказуемых Вороньих кортах невелики. «Мы берем на себя такой огромный дополнительный риск с кем-то из резервации», - говорит Нэнси Вермёлен из Square One. «Если бы я знал, что контракты будут исполняться, я мог бы вести там гораздо больше дел».

В то время, когда в центре внимания находится 1% самых богатых людей, взгляд на 310 индейских резерваций страны, где проживают многие из 1% самых бедных в Америке, может быть более полезным.Чтобы объяснить бедность резерваций, люди обычно указывают на алкоголизм, коррупцию или показатели отсева из школ, не говоря уже о больших расстояниях до рабочих мест и пыльных неосвоенных землях, которые не подходят для большого роста. Но это всего лишь симптомы. Процветание строится на правах собственности, а в резервациях часто нет ни того, ни другого. Они демонстрируют, что происходит, когда права собственности слабы или отсутствуют.

Резервация Ворона, Монтана. (Фотография предоставлена ​​/ Морин Салливан)

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

Это приводит к тому, что экономисты называют трагедией общин: если каждый владеет землей, никто не владеет ею. Таким образом, результатом является некачественное жилье и бесплодный, запущенный вид, который возникает из-за недостатка инвестиций, чрезмерного использования и ухудшения состояния окружающей среды.Это общий вид во всем мире, где отсутствуют надежные права собственности - в большей части Африки и Южной Америки, в проектах жилищного строительства в городских районах и многоквартирных домах с контролируемой арендной платой в США, в резервациях Индии.

Более трети 2,3 миллиона акров резервации Кроу находится в индивидуальной собственности, и, как показывают спутниковые карты Google, контраст с коммунальной землей - часто по другую сторону забора - разительный. Терри Андерсон, исполнительный директор Исследовательского центра собственности и окружающей среды в Бозмане, штат Монтана, является соавтором исследования, показывающего, что частная земля на 30-90% более продуктивна в сельском хозяйстве, чем прилегающая земля, находящаяся в доверительном управлении.И это не потому, что земля лучше: исследование 13 резерваций на Западе поместило 49% земель в четыре высших класса качества, в то время как только 38% земель в окружающих округах получили такую ​​высокую оценку. Для резервации Ворона 48% земель составляли четыре высших класса; только 33% прилегающих земель. «Необработанное качество земли не сильно отличается, отличается объем инвестиций в эту землю», - говорит он.

Национальный памятник Поле битвы Литтл-Бигхорн, Монтана.(Фотография предоставлена ​​/ Морин Салливан)

Канада сталкивается с теми же проблемами со своими 630 бандами - как там называют племена - но благодаря усилиям упорного реформатора, есть толчок к приватизации земель резерваций. Мэнни Джулс, бывший глава группы индейцев Камлупса в Британской Колумбии, выстраивает поддержку Закона о собственности коренных народов, который позволит бандам отказаться от государственной собственности на свою землю и передать ее в племенную и частную собственность.Резервы станут новыми образованиями, которые будут иметь некоторые из полномочий муниципалитетов, провинций и федерального правительства по предоставлению школ, больниц и других услуг, а также по принятию законов о зонировании. Он ожидает, что закон будет внесен в парламент в начале 2012 года и уверен, что будет одобрен к концу года. Выдвигает вопрос острый жилищный кризис с резервами. Без прав частной собственности мало жилья строится даже при росте населения Индии, и Ассамблея коренных народов оценивает, что заповедникам немедленно потребуется 85 000 новых домов; правительство строит только 2200 в год.

«Рынки не могут работать в резервных землях», - говорит Жюль. «Мы были выведены из экономики по закону. Когда у вас нет индивидуальных прав собственности, вы не можете строить, вы не можете быть связанными, вы не можете передавать богатство. Многие малые предприятия никогда не открываются, потому что люди не могут использовать собственность [для сбора средств]. Этот поступок освободит наш предпринимательский дух, но потребует освобождения и нашего воображения. Мы должны стать частью национальной и глобальной экономики.”

Но даже если Джулс добьется успеха, в США нет такого реформатора, который возглавил бы здесь атаку. Любые попытки земельной реформы должны проходить через Бюро по делам индейцев. Но это бюро, изначально входившее в состав военного министерства и одно из старейших ведомств федерального правительства, не собирается готовить почву для собственной кончины, подписывая усилия по приватизации земель резерваций. Бюро сталкивалось с такой ситуацией и раньше: согласно Закону Дауэса 1887 года земля могла быть выделена отдельным индейцам, но к 1934 году было приватизировано так много земли, что Конгресс изменил курс, и общинная племенная собственность снова вернулась в его пользу.«Распределение ресурсов угрожало бюро, поэтому у него был стимул прекратить процесс», - говорит Доминик Паркер, профессор экономики в Университете штата Монтана. В любом случае советы племен не захотят отказываться от покровительства и власти, которые дает им контроль над огромными участками земли. А 2,5 миллиарда долларов в год, которые Вашингтон тратит на программы для коренных американцев, являются мощным сдерживающим фактором для перемен. «Для бюро и других узких кругов безопаснее оставаться с запутанной системой собственности на землю, чем улучшать права собственности», - говорит он.В бюро от комментариев отказались.

Плюс есть практические вопросы. Любой индиец, не получивший явного права на землю к 1934 году, оставался с долей земли резервации, находившейся в доверительном управлении. С каждым поколением каждая доля делилась между большим количеством членов семьи, и сегодня сотни людей могут частично претендовать на одну долю доверительной земли. Часто отсутствуют записи о том, где находятся многие из этих людей. В резервации Кроу 1 миллион из 2,3 миллиона акров земли находится в доверительном управлении для таких лиц.Закон Дауэса создал еще одну проблему: неиндийские владельцы приватизированной земли в резервации всегда сталкивались с юридическими вопросами о том, подпадают ли они под юрисдикцию властей племени. Клетчатая структура частной и доверительной земли в некоторых резервациях затрудняет предоставление племенам услуг и планирование землепользования.

Андерсон четко ставит вопрос о выборе племен. «Если вы не хотите частной собственности и хотите оставаться под опекой, то я говорю:« Хорошо.'Но вы останетесь недоразвитыми; ты не станешь богатым ".

Проблемы резерваций выходят далеко за рамки того, что у жителей нет нужных стимулов для улучшения своего окружения. За некоторыми исключениями, даже казино не получили особой выгоды от нескольких десятков резерваций, которые их построили. Компании и инвесторы часто неохотно ведут дела по резервациям - от регистрации франчайзи фастфуда до кредитования проектов казино - потому что исполнение контрактов в соответствии с племенным законодательством может быть ненадежным.Индийские страны могут быть небольшими, и проблемы возникают не так часто, поэтому коммерческие кодексы не очень хорошо разработаны и отсутствуют прецеденты. А подсудимые из Индии имеют преимущество в домашнем суде. «Нам еще очень далеко до надежного делового климата», - говорит Билл Йеллоутейл, бывший чиновник компании Crow и бывший сенатор штата Монтана. «Компании, приезжающие в резервацию, спрашивают:« Во что я ввязываюсь? »Суды племен не являются надежным форумом для разрешения споров».

Многие резервации богаты природными ресурсами, но спешить с их освоением не стоит, учитывая запутанный вопрос прав собственности и риск крупных инвестиций без надежной правовой основы.«У нас есть 9 миллиардов тонн высококачественного угля, находящегося в резерве, который практически не используется», - говорит Йеллоутейл. «И природный газ. Потенциал развития в изобилии, но этот потенциал никогда не реализуется ». Действительно, план по переработке угля в жидкие углеводороды на 7 миллиардов долларов потерпел крах в апреле, хотя в июле он был восстановлен в сокращенной версии. Андерсон добавляет, что с любыми инвестициями «племя может изменить сделку постфактум, потому что оно суверенное».

Некоторые племена предпринимают шаги для улучшения своих юридических структур, например, принимают новые торговые кодексы, чтобы сделать свои законы более единообразными.Согласно исследованию Андерсона и Паркера, за 30-летний период в резервациях, в которых была принята судебная система штатов, в которых они расположены, доход на душу населения рос на 30% быстрее, чем в резервациях, в которых этого не произошло. Отдельное исследование Паркера показывает, что у коренных американцев на 50% больше шансов получить одобрение заявки на получение кредита, когда кредиторы имеют доступ к судам штата. «Включение резерваций под юридическую юрисдикцию штатов и содействие совершенствованию правовых кодексов и более эффективному функционированию судебных систем поможет племенам в освоении своей земли», - говорит Андерсон.

Большим препятствием для этих реформ может быть не логистика или особые интересы, а культура резерваций и поколения за поколениями зависимости. В самом деле, объявление на доске объявлений в Гаррёуэне, штат Монтана, внутри резервации Кроу и рядом с местом последней битвы Кастера, объявляет, когда следующий раунд «чеков на подушевую оплату» - полученных от трастового дохода Crow Nation - будет отправлен по почте. .

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

Но Желтохвост считает, что ситуация улучшается.Он говорит, что предпринимателей стало больше, чем 20 лет назад, поскольку в Монтане и других местах возникли сети деловых людей из числа коренных американцев. «Начать надо с микрокредитов, поощрения малого бизнеса. Затем мы должны принять решение покинуть резервацию, потому что наиболее успешные захотят разветвляться. Предпринимателям придется высовывать шею и быть образцом для подражания. Нам, индийцам, придется это сделать ».

.

No related posts.