Двигатель 2 узет: Двигатели Тойота 4 Раннер | Проблемы, ремонт, надежность

Содержание

Двигатель Toyota 2UZ FE технические характеристики, масло, ГРМ, ресурс

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

Содержание страницы

Список автомобилей с 2UZ FE

За период серийного производства данный двигатель устанавливался на определённые марки автомобилей, в разных странах мира:

В ОАЭ 2UZ FE устанавливали:

  1. С сентября 2007 по март 2012 года на
    Toyota Land Cruiser, одиннадцатого поколения, suv, кузов 100.
  2. С апреля 2005 по декабрь 2007 года на Toyota Land Cruiser, десятого поколения, второй рестайлинг, suv, кузов 100.
  3. С августа 2002 по март 2005 года на Toyota Land Cruiser, десятого поколения, рестайлинг, suv, кузов 100.
  4. С января 1998 по июль 2002 года на Toyota Land Cruiser, десятого поколения, suv, кузов 100;

В России данный двигатель использовали:

  1. С сентября 2007 по март 2012 года на Toyota Land Cruiser одиннадцатого поколения, suv, кузов 200.
  2. С апреля 2005 по декабрь 2007 года на Toyota Land Cruiser десятого поколения, второй рестайлинг, suv, кузов 100.
  3. С августа 2002 по март 2005 года на Toyota Land Cruiser, десятого поколения, рестайлинг, suv, кузов 100.
  4. С января 1998 по июль 2002 года на Toyota Land Cruiser, десятого поколения, suv, кузов 100.

В Японии 2uz был сердцем:

  1. С сентября 2007 по декабрь 2011 года на Toyota Land Cruiser, одиннадцатого поколения, suv, кузов 200.
  2. С апреля 2005 по июнь 2007 года на Toyota Land Cruiser десятого поколения, второй рестайлинг, suv, кузов 100.
  3. С августа 2002 по март 2005 года на Toyota Land Cruiser, десятого поколения, suv, кузов 100.
  4. С января 1998 по июль 2002 года на Toyota Land Cruiser десятого поколения, suv, кузов 100.

В Америке данный мотор использовали:

  1. С апреля 2005 по октябрь 2007 года на Toyota Land Cruiser десятого поколения, второй рестайлинг, suv, кузов 100.
  2. С августа 2002 по март 2005 года на Toyota Land Cruiser десятого поколения, рестайлинг, suv, кузов 100.
  3. С января 1998 по август 2002 года на Toyota Land Cruiser, десятого поколения, suv, кузов 100.
  4. С апреля 2005 по июнь 2007 года на Toyota Land Cruiser Cygnus, первого поколения, второй рестайлинг, suv, кузов J100.
  5. С августа 2002 по март 2005 года на Toyota Land Cruiser Cygnus, первого поколения, рестайлинг, suv, кузов J100.
  6. С декабря 1998 по июль 2002 года на Toyota Land Cruiser Cygnus первого поколения, suv, кузов J100.
  7. С ноября 2007 по январь 2017 года на Toyota Sequoia второго поколения, suv, кузов XK60.
  8. С августа 2004 по декабрь 2007 года на Toyota Sequoia, первого поколения, рестайлинг, suv, кузовы исполнения XK30 и XK40.
  9. С сентября 2000 по июль 2004 года на Toyota Sequoia, первого поколения, suv, кузовы XK30, XK40.
  10. С ноября 2006 по апрель 2009 года на Toyota Tundra, второго поколения, пикап, кузов XK50.
  11. С июля 2002 по январь 2007 года на Toyota Tundra первого поколения, рестайлинг, пикап, кузовы XK30, XK40.
  12. С мая 1999 по июль 2002 на Toyota Tundra первого поколения, пикап, кузовы XK30, XK40.

Кроме этого 2UZ FE использовали:

  1. С августа 2005 по август 2008 г., на Toyota 4Runner, четвёртого поколения, рестайлинг, suv, кузов N210.
  2. С августа 2002 по июль 2005 г., на Toyota 4Runner, четвёртого поколения, suv, кузов N210.

История создания и доработок ДВС Тойота 2 UZ FE

В 90-х годах прошедшего века корпорация Toyota приобрела большой опыт использования двигателей “большой восьмёрки” в различных условиях эксплуатации. Восьми цилиндровые двигатели устанавливались как на крупные внедорожники, так и на спортивные автомобили. Данное семейство моторов удостоили своим вниманием так же премиальные седаны. Старший родственник, рассматриваемого в этой статье двигателя, четырёх литровый 1UZ FE, использовался в каждом японском автомобиле, где требовалась большая мощность.

Благодаря широкому использованию 1UZ FE, компания Тойота, в сжатые сроки собрала огромное количество исследовательских и статистических данных. При таком количестве полученного опыта, TOYOTA смогла быстро разработать и выпустить в серийное производство самую объёмную версию двигателей семейства UZ. Это был 4.7 литровый силовой агрегат 2UZ-FE. Полномасштабное серийное производство нового ДВС началось в 1998 году. Предназначался этот железный силач, для внедорожников Toyota и Lexus хай-энд класса.

Первая версия 2uz производилась без системы VVTi. Производственные цеха по выпуску данного мотора находились в двух странах: а Японии, город Тохара и в США, штате Алабама. Чтобы соответствовать своему назначению, эксплуатации на тяжёлых внедорожника и пикапах, блок двигателя изготовили из чугуна. На других моторах семейства uz используется алюминиевый блок с тонкостенными чугунными гильзами.

Диаметр цилиндра нового мотора больше, нежели на предыдущих модификациях, он равен 94 мм., длинна хода поршня 84 мм. Степень сжатия на 2uz снизили до 9.6:1. Такие данные для мотора подобраны специально, чтобы он на средних оборотах мог выдавать максимальный крутящий момент. Что у проектировщиков неплохо получилось. Так 2 UZ, первой версии, без системы VVTi выдаёт мощность при 4800 оборотов мин., равную 230 л., сил, а пиковый момент при средних оборотах 3600 в мин., составляет 422 Нм.

В 2005 году была осуществлена модернизация второго поколения двигателей семейства UZ. Обновлённая модификация, на впускной распределительный вал получила систему, изменяющую фазы газораспределения, VVTi. Кроме этого изменения претерпела дроссельная заслонка, она получила электронное управление. Благодаря этим доработкам, максимальная мощность 2uz fe с фазорегулятором при 4800 оборотов мин., увеличилась до 271 л., силы. А максимальный момент подрос до 4400 Нм., при средних оборотах коленчатого вала.

Выпуск успешного силового агрегата 2UZ FE с системой изменения фаз, механизма газораспределения, продолжался до конца 2010 года. Затем его вытеснили более современные силовые агрегаты семейства UR.

Нужно отметить, что автомобили использующие рассматриваемый двигатель, многократно завоёвывали призовые места в различных соревнованиях. Факторами для множественного успеха были: высокая мощность, максимальный момент на средних оборотах коленвала, умеренный расход горючего, низкий порог вибраций и шума, компактное размещение навесного оборудования. Эти характерные черты 2 UZ FE, делали мотор на рынке того времени, одним из самых лучших силовых агрегатов.

Технические данные 2 UZFE

Самым большим двигателей серии UZ, является мотор второго поколения. Объём его цилиндров составляет 4664 куб., см. Производился данный ДВС в Японии, префектура Айти, город Тохара. Так же производство 2 uz велось в Америке, штат Алабама, Toyota Motor Manufacturing.

  • Это бензиновый, восьми цилиндровый, четырёхтактный двигатель, имеющий V образное расположение цилиндров, угол развала прямой.
  • Годы выпуска мотора первой версии без VVTi — с 1998 по 2005 год. Вторая версия с установленным фазорегулятором производилась с 2005 по 2010 годы.
  • Материал изготовления БЦ особо прочный чугунный сплав. Данный двигатель имеет две головки БЦ, каждая для четырёх цилиндров. Система питания 2UZ инжектор, электронный много точечный впрыск. Рабочая температура ДВС 90С.
  • Система ГРМ — DOHC, четыре распределительных вала, по два для каждой головки, 32 клапана, четыре для каждого цилиндра. Система ГРМ после 2005 года обустроена фазорегулятором. Гидравлические компенсаторы в системе ГРМ отсутствуют. Система зажигания независимая, электронная, каждый цилиндр имеет индивидуальную катушку зажигания.
  • Длинна хода поршня меньше диаметра цилиндров 84 и 94 мм., степень сжатия 9.6:1. Мощность силового агрегата, без системы VVTi, при 4800 оборотов мин., составляет 230 Нм., пиковый крутящий момент при 3600 оборотов мин., около 420 Нм. Двигатель 2UZ с фазорегулятором имеет мощность 271 л., сил и момент 440 Нм., при тех же оборотах коленчатого вала.

Расход топлива

Соответствие экологическим нормам по выбросам вредных веществ Евро 2, Евро 3. Вес силовой установки 245 кг. Рекомендуемое горючие — бензин АИ 95. Расход топлива при городской езде составляет 16.5 л., на 100 км., пробега, при езде по трассе 10 литров, общий расход равен 12.5 литров на 100 км., пробега.

Расход масла

Допустимый расход моторной смазки около 1 литра на 1000 км., пробега. Используемые виды масла: 0w30, 5w40, 10w40, 5w30, 10w30. Количество масла в картере 6.2 литра. Замену моторной смазки нужно проводить не позже чем через 10 тыс., км., пробега. Но лучше, для большего ресурса ДВС, замену масла делать через 5000 км.

Ресурс двигателя

Ресурс 2UZ FE составляет 500 тыс., км., пробега. При хорошем обслуживании и бережной эксплуатации может значительно превысить официальные данные.

Маркировка японских ДВС

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

Рассмотрим маркировку ДВС на примере 2UZ FE:

  1. на первом месте всегда стоит цифра, она означает поколение моторов данной серии, здесь это второе поколение;
  2. дальше идут два символа, в виде заглавных латинских букв. Они означают семейство ДВС. В нашем случае мотор семейства UZ. Где U — это линейка силовых агрегатов, а Z указывает на применяемое топливо — бензин;
  3. следующие символы латинские заглавные буквы, их может быть три или две. В них кодируются особенности автомобиля его исполнение;
  4. символ F информирует о применяемой системе ГРМ на рассматриваемом двигателе. Здесь это система DOHC, состоящая из двух головок, в каждой находятся по два распределительных вала верхнего расположения и 32 клапана. Гидрокомпенсаторы отсутствуют, система VVTi используется с 2005 года;
  5. последний в названии символ E, информирует об электронном, много точечном впрыске, применяемом на данном моторе.

Собрав всю информацию, можно сказать, что рассматриваемый ДВС — второго поколения, семейства UZ, использует топливо бензин, обустроен системой ГРМ — DOHC, и электронным впрыском.

Описание ДВС 2UZ FE

В конце девяностых годов вырос спрос на мощные двигатели. В связи с этим инженеры корпорации Тойота разработали новый бензиновый двигатель, с самым большим объёмом семейства UZ. В 1998 году начался серийный выпуск новой модели. Силовой агрегат 2 UZ FE предназначался для эксплуатации на тяжёлых джипах и мощных спортивных автомобилях. Постепенно этот восьмой мотор вытеснил с рынка шести цилиндровый, рядный ДВС 1FE. В отличие от других моторов семейства UZ, второе поколение получило чугунный блок, такой корпус мотора был гарантией долговечности и надёжности.

Цилиндры нового ДВС получили диаметр 94 мм. Коленвал силового агрегата обеспечивал ход поршня равный 84мм. В результате получился очень успешный низовой мотор, с объёмом цилиндров 4.7 литров.

Несмотря на чугунный блок, головки БЦ по-прежнему выполнены из алюминиевого сплава. На двигателе используется две симметричные головки, каждая для четырёх цилиндров одной стороны. В головках, находятся по два вала верхнего расположения, для каждого цилиндра предусмотрено 4 клапана. У рассматриваемого мотора есть две версии. Первая версия 2UZ FE выпускалась до 2005 года.

Затем мотор доработали и установили на него систему VVTi. С системой изменения фаз распределения газа, движок стал выдавать 271 л., силу. Хотя без фазорегулятора, данный двигатель развивал мощность, не превышающую 230 л., сил. На обеих версиях 2UZ гидрокомпенсаторы не предусмотрены. Регулировку тепловых зазоров в клапанах следует проводить способом подбора шайб. Период регулировки составляет около 100 тыс., км. В случае появления стука в верхней части двигателя, регулировать тепловой зазор в клапанах нужно раньше.

На рассматриваемом двигателе, механизм привода газораспределения осуществляется зубчатым ремнём от зубчатого шкива коленчатого вала. Крутящий момент передаётся на зубчатый шкив впускного распределительного вала. Выпускной распределительный вал приводиться в работу от впускного вала, через шестерёнчатую передачу. Нужно отметить, что кроме привода ГРМ, ремень приводит в работу водяной насос. Тем самым подвергаясь двойной нагрузки. Поэтому опытные механики не рекомендуют верить производителям зубчатых ремней, гарантирующих ресурс работы своего изделия в 100 тыс., км. Известно не мало случаев, когда ремень приходил в негодность задолго до этого пробега. Следовательно, есть смысл сократить период замены ремня ГРМ до 60 тыс., километров пробега.

Серийный выпуск 4.7 литрового ДВС успешно продолжался до 2011 года. Затем он уступил место на главном конвейере более экологичному и современному 1UR FE.

Характерные неисправности

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

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

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

Инновационные технологии на ДВС 2UZ FE

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

Компрессор

Для того, чтобы повысить мощность силового агрегата, компания TRD (Toyota Racing Development) устанавливает на 4.7 литровый двигатель компрессорный кит — механический нагнетатель. Данная инновационная деталь увеличивает мощность данного движка до 350 л., сил. И что немаловажно, данная модернизация не уменьшает ресурс и надёжность рассматриваемого мотора;

ETCS

На 2UZ применена Electronic Throttle Control System. ETCS — это интеллектуальная, электронная система, управляющая положением дроссельной заслонки. Данная система существенно улучшает контроль над работой силового агрегата, особенно в условиях бездорожья и при экстремальных условиях вождения, тем самым обеспечивая комфорт и удобство управления автомобилем в любых дорожных ситуациях;

Starter Control System

На рассматриваемом двигателе впервые применена система Starter Control System. Это система, управляющая включением стартера. Она удерживает стартер от пуска, до того времени, когда специальный датчик, определит готовность горючей смеси в камерах сгорания к воспламенению. Эта система способствует росту надёжности двигателя и увеличивает ресурс работы стартера;

Toyota Direct Ignition

На 2UZ применили систему направленного зажигания, Toyota Direct Ignition, кратко TDI. Данная система способствует точности и надёжности опережения угла зажигания, что гарантирует полное и лучшие сгорание горючей смеси. А это напрямую связано с улучшением экологичности и экономичности силового агрегата.

Особенности эксплуатационного обслуживания

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

Замена свечей на 2UZ FE

Регламент замены масла рекомендуемый

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

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

Регулировка клапанов на 2UZ-FE

Минимальный период замены масла

Чтобы этого не произошло, имеет смысл выполнять мероприятия по замене масла через 5 тыс., км. Даже если моторная смазка окажется поддельной, до 5000 км., пробега смазочных свойств останется достаточно, чтобы защитить трущиеся детали силового агрегата. Сокращение периода замены масла вдвое, гарантирует защиту деталей мотора в любых, даже самих жёстких условиях.

Замена ремня ГРМ

Важным мероприятием по обслуживанию мотора считается замена ремня привода газораспределительного механизма. Ресурс работы ремня ГРМ, заявленный производителем 100 тыс., км. Однако ремень вращает не только распределительный вал, он общий для всего навесного оборудования. А значит, может перескочить или лопнуть при меньшем пробеге нежели 100 тыс., км.

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

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

Двигатель Toyota 2UZ. Узет — лучше для мужчины нет. | Андрей Хомяков

2uz-fe под капотом Land Rover Discovery

2uz-fe под капотом Land Rover Discovery

Двигатели V8 от Тойоты очень популярны не только на внедорожниках и бизнес-седанах. Часто они обретают вторую жизнь в других автомобилях, или автомобиль обретает вторую жизнь. Это как посмотреть. Свапануть Газель, Гелик, УАЗик или ГАЗ-66 — очень распространенное явление. Линейка UZ включала в себя 3 мотора V8 разного объема. 1 UZ — 4.0 литра, 2 UZ — 4.7 литра, 3UZ — 4.3 литра.

Из этой тройки только 2 UZ имел настоящий чугунный блок, который стал фундаментом неограниченного ресурса этого двигателя. Более того, тюнинговое подразделение Toyota Racing Development (TRD) разработало на него кит для увеличения мощности — компрессор, который ставится как родной, но это отдельная история.

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

Родился данный двигатель в 1998 году и стал самым объемным двигателем из серии UZ. В 2005 году этот двигатель получил систему VVT-i на впуске, в результате чего двигатель начал выдавать те самые «налоговые» 288 л.с. В 2011 году Тойота заменила его на двигатель серии UR объемом 4.6 литра 1UR-FE, который стал более мощным, легким, экономичным и …. менее ресурсным.

Да, Тойота не исключение. Чтобы укладываться в новые экологические нормы токсичности, пришлось вносить в конструкцию изменения, которые не делают двигатель надежнее. 1UR-FE имеет склонность к закоксовке и залеганию поршневых и маслосъемных колец, что приводит к масложору.

КОНСТРУКЦИЯ

Блок цилиндров — из высокопрочного чугуна, V8 c развалом в 90 градусов.

ГБЦ — головки выполнены из сплава алюминия. Каждый цилиндр имеет 4 клапана. Гидрокомпенсаторов нет. На впускном распредвале стоит система VVT-i. Проще говоря — фазовращатель.

ГРМ — зубчатый ремень, который вращает впускные распредвалы, которые через зубчачую передачу вращают выпускные распредвалы. Сами валы цельнолитые.

Топливная система — распределенный впрыск.

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

Система охлаждения — помпа располагается в развале блока и приводится в движение ремнем ГРМ.

Как видите, конструкция простая, как у «калаша». Простота — залог надежности.

ЭКСПЛУАТАЦИЯ

Двигатель получился неприхотливым в обслуживании. Замена масла раз в 10 т.км. в смешанном цикле или по трассе, в городе раз в 7.5 т.км., особенно если двигатель много работает на холостом ходу. К маслу он не сильно требователен, подойдет универсальное 5W30, если вы не живете в условиях экстримальных морозов. Допуск масла должен быть не ниже SL/GF-3 по классификации API. То есть подойдет как Lukoil Genesis Armortech JP 5W30, так и IDEMITSU ZEPRO TOURING 5W30. Сервисный объем 6.2 литра.

Раз в 100 т.км. по регламенту требуется замена ремня ГРМ и свечей зажигания. Вместе с ремнем логично заменить и помпу охлаждения.

ИТОГ

Двигатель получился очень удачный. Его смело можно рекомендовать к покупке даже с большим пробегом. Главное, будьте готовы его заправлять. Расход по городу с плотным траффиком на TLC200 может достигать 30 литров. Что по современным меркам немного многовато.

Если интересно узнать отличия 4.7 2UZ-FE на 288 л.с. от 4.6 1UR-FE на 309 л.с. то ставь палец вверх! Удачи на дорогах!

Uz Fe — OLX.ua

ГБЦ Lexus 3uz fe

Автозапчасти и аксессуары » Автозапчасти

Черкассы 11 март

Днепр, Центральный 9 март

Одесса, Суворовский 19 февр.

126 818 грн.

Договорная

Одесса, Малиновский 15 февр.

Регулировка клапанного механизма на двигателях Lexus и Toyota серии UZ, фото этапов

Lexus LX470 (Toyota Land Cruiser 100), Lexus GX470 оснащены двигателем 2 uz fe.

Двигатель серии UZ — это V-образный 8-цилиндровый двигатель с расположением 4 клапанов на цилиндр. Всего было 3 поколения двигателей серии UZ-FE различного рабочего объема и мощности. (1UZ-FE, 2UZ-FE, и 3UZ-FE). Двигатели выпускались с 1989 г. по 2011 г. Сам по себе UZ-FE крайне надежен и в народе нередко именуется «миллионником». Этот двигатель способен пройти 500 тыс. км и более.

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

Проверка зазоров клапанного механизма 2 UZ FE.

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

Регулировочные шайбы двигателя 2 UZ FE.

Демонтаж распределительного вала 2 UZ FE.

Демонтаж толкателя.

Демонтаж регулировочной шайбы. Прогоревшие клапаны.

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

характеристики, масло и ГРМ, проблемы

Бензиновый двигатель Toyota 2UZ-FE устанавливался на автомобили марки Тойота и Лексус с 1998 года. Агрегат с чугунным блоком и большим объемом выпускался в Японии и США, был специально разработан под пикапы и габаритные внедорожники. Восьмицилиндровый ДВС с двумя алюминиевыми головками, на каждую из которых приходится по два распределительных вала, оснащался многоточечным впрыском (с электронной регулировкой).


Бензиновый мотор 2UZ-FE

Характеристики двигателя 2UZ-FE


Бензиновый двигатель Toyota 2UZ-FE (ссылка на источник изображения)
Технические характеристики бензинового двигателя Тойота с маркировкой 2UZ-FE:

Годы выпуска силовой установки — в период с 1998 по 2011 год.

Расход топлива

Потребление бензина двигателем Тойота с маркировкой 2UZ можно рассмотреть на примере внедорожника Ленд Крузер 200 с 5АКПП и постоянным полным приводом. В городе автомобиль потребляет 19 л топлива, на трассе 11,7, а в смешанном цикле расход составляет 14,4 л.


Toyota Land Cruiser 200

Расход топлива на Ленд Крузер 100 с 5АКПП и постоянным полным приводом иной — 21,5 в городской черте, 13,4 за городом, 16,3 в смешанном цикле.


Land Cruiser 100

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

Toyota Land Cruiser 100 V8 VX: Макияж для адмирала

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

Внутри новостей больше. Отныне 100 VX оснащается оптитронной приборной панелью, загорающейся при включении зажигания, – такие же можно встретить на «Лексусах» и дорогих «Короллах».

Проведена реорганизация центральной консоли. Во главу ее поставлен многофункциональный информационный дисплей, под которым находится CD/кассетный ресивер с чейнджером на 6 дисков и управлением базовыми функциями кнопками на руле. Громкость звука аудиосистемы и его частотные характеристики меняются в завимости от уровня наружных шумов. На машине появилась система климат-контроля, причем в распоряжении задних пассажиров есть собственные блоки управления климатической установкой и «музыкой».

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

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

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

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

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

А меньше всего удовольствия доставляет прохождение поворотов – сказываются низкая чувствительность рулевого, невнятное реактивное усилие и большие крены. Хотя особо беспокоиться не стоит: на страже безопасности стоит разветвленный комплекс электронных систем во главе с неотключаемой системой стабилизации VSC, которая при возникновении угрозы потери устойчивости регулирует обороты двигателя и распределение тормозных усилий между колесами.

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

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

В чем можно упрекнуть Land Cruiser 100? Наверное, только в недостаточной роскоши интерьера. К счастью, этот пробел устраним: в нашу страну начались официальные поставки модели Lexus LX470, которую и можно назвать самым богатым исполнением «сотки». Цена вопроса – двадцать тысяч долларов сверху тех семидесяти, что просят за Land Cruiser 100 VX.

Технические особенности

В 1998 году концерн Тойота представил новый двигатель из серии UZ.


Двигатель 2UZ-FE
ДВС с маркировкой 2UZ-FE в отличие от родственных моторов линейки получил внушительный объем в 4,7 л. Блок цилиндров из чугуна увеличил ресурс агрегата. Увеличился и диаметр цилиндров, впоследствии на автомобили с этим движком была добавлена система изменения фаз газораспределения VVT-I.


ГБЦ двигателя 2UZ-FE с распредвалами

Двигатель Тойота 2УЗ-ФЕ оснащен двумя распредвалами, на каждый цилиндр приходится по 4 клапана. Ремень ГРМ зубчатый, его приблизительный ресурс составляет 100 тысяч км. При достижении этой отметки нужно позаботиться о замене, чтобы не допустить обрыва и поддерживать ровную работу ДВС.


Рем. комплект ГРМ двигателя 2UZ-FE

Путь Легенды

История внедорожников под маркой Toyota началась в середине прошлого века. После войны Япония переживала не лучшие времена, но ее промышленность потихоньку вставала с колен, а в США тем временем был объявлен конкурс на поставку легких полноприводников для военных. Так и появился внедорожник Toyota BJ.

С этого простого на вид внедорожника началась история легендарного имени Land Cruiser

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

В 1951 году на одном из прототипов этого внедорожника японский водитель-испытатель Ичиро Таира совершил легендарное восхождение к пункту №6 на знаменитой горе Фудзи — до BJ туда не забирался ни один автомобиль. После этого партию сразу из 289 таких машин заказало Национальное полицейское агентство Японии, но главное — был выигран и военный тендер США: американцев восхитила проходимость и неприхотливость внедорожника Toyota. После отладочных работ серийное производство стартовало в 1953-м, а годом позже BJ получил и новое имя — Land Cruiser!

Cерия 20 — глубоко модернизированный внедорожник BJ

В 1955-м была представлена модификация Toyota Land Cruiser 20. Этот внедорожник получил усовершенствованную подвеску с резиновыми сайлент-блоками, а также укороченную колесную базу — это благотворно сказалось на маневренности. Появился в гамме и удлиненный вариант — более грузоподъемный, он был представлен в виде пикапа и пассажирского автомобиля с многоместным салоном: в нем был даже кондиционер! В движение автомобиль 20-й серии приводился новым двигателем серии F. Этот агрегат с чугунным блоком развивал 105 л.с. и оказался настолько удачным, что с незначительными изменениями прожил на разных моделях компании до 1992 года!

Ну а в 1960-м 20-ю модель на конвейере сменило следующее поколение — Toyota Land Cruiser 40. Самым ярким внешним отличием этого внедорожника стала стальная рамка, визуально объединяющая фары и решетку радиатора. Также стали более квадратными колесные арки. Главное техническое новшество модели — появление понижающего ряда передач в трансмиссии. Помимо бензиновых двигателей, для 40-й серии были доступны и атмосферные дизели.

И сейчас находятся любители покорять бездорожье именно на Land Cruiser 40

Предлагался для этой версии и вариант со сверхдлинной колесной базой и совершенно новым, более легковым кузовом — чуть позже, в 1967 году, он получил собственное обозначение Toyota FJ55 и был выделен как отдельная модель. Этот автомобиль по-прежнему не пасовал на серьезном бездорожье, но был лучше «сороковки» приспособлен к движению по асфальту — к примеру, высокооборотистый двигатель серии 2F позволял набирать на магистрали до 130 км/ч. Более того, FJ55 успешно прошел и первые американские ­краш-тесты — на скорости 50 км/ч.

Ну а дальнейшие усилия инженеров компании в создании комфортного на асфальте и неубиваемого на бездорожье автомобиля привели к выходу следующего поколения — в 1976 году свет увидел внедорожник Toyota Land Cruiser 60. Именно эту модель принято считать родоначальником современных «больших» машин марки Toyota. Автомобиль получил новый кузов, комфортный салон с раздельными передними креслами, улучшенную шумоизоляцию и множество «люксовых фишек» того времени. Оснащался он бензиновыми двигателями типа 2F и дизелями типа B. Также стала доступной и пятиступенчатая коробка передач.

Тем временем Land Cruiser 40-й серии продолжал выпускаться — и пробыл на конвейере аж до 1984 года. Но, конечно, к тому времени его конструкция уже стала архаичной. Нужна была достойная замена — и ее представили в том же 1984-м в виде внедорожника Toyota Land Cruiser знаменитой серии 70. Вот уж на самом деле — легенда в клане легенд!

По сути, этот автомобиль был создан с чистого листа — и сразу был доступен в двух версиях. Первый, «тяжелый» вариант «семидесятки» получил обозначение HD — Heavy Duty. Это был наследник грубых армейских внедорожников — со всеми соответствующими атрибутами. Помимо стандартных вариантов, на его основе выпускались и специальные автомобили — для спасателей, медиков и даже шахтеров. А благодаря буквально абсолютной надежности эту машину очень любили и путешественники. К примеру, супруги Пауль и Бритта Боген на таком внедорожнике совершили семилетнее кругосветное путешествие! Они проехали через 63 страны по самому разному ландшафту (от песков пустынь до гор и снежной тундры), а общий пробег составил больше 280 тысяч километров. По возвращении домой пара написала в компанию Toyota письмо с благодарностями!

Производство Land Cruiser 70 HD было остановлено в 2007 году. Но любители данной модели буквально забросали руководство компании просьбами о возобновлении выпуска, и концерн Toyota пошел на беспрецедентный шаг: в 2014 году к 30-летнему юбилею модели ее выпуск небольшими квотами был возобновлен.

Легкая серия Land Cruiser 70 позже получила собственное имя Prado

Легкая серия внедорожника Toyota Land Cruiser 70 сначала получила обозначение LD — Light Duty. Это был комфортабельный легковой полноприводник для дальних путешествий. Его внедорожный арсенал был проще, но для большинства дорожных ситуаций его хватало за глаза.

В 1990 году все легкое семейство получило собственное имя Toyota Land Cruiser Prado, а в 1996-м свет увидел автомобиль серии 90. Эти комфортабельные и безопасные семейные машины еще встречаются на дорогах — хотя возраст многих из них уже перевалил за 25 лет. Prado 90-й серии оснастили независимой подвеской передних колес, благодаря чему он стал лучше управляться на асфальте и получил дополнительные бонусы для езды по бездорожью.

Land Cruiser Prado серии 90 — отличный легковой автомобиль повышенной проходимости

В 2002 году было представлено следующее поколение Prado — серия 120. Это был уже практически современный автомобиль. Его дизайн впервые был разработан за пределами Японии — в центре промышленного дизайна во Франции. В этом поколении Prado получил ряд современных систем безопасности и комфорта: в салоне появился климат-контроль и мультимедиасистема с большим экраном…

Дизайн Prado 120 создавался во Франции

Но вернемся к полноразмерным внедорожникам Land Cruiser. В конце восьмидесятых годов в компании Toyota серьезно модернизировали свой флагман 60-й серии — так появился Land Cruiser 80. Автомобиль получил ряд новых решений, среди которых была и пружинная подвеска всех колес, и доработанная ходовая часть, и новые, еще более мощные и надежные двигатели. На передней панели появилось место для подключения навигационной аппаратуры, а на крыше — рейлинги.

Ну а в 1999 году был представлен Land Cruiser 100. Специально для этой модели были разработаны новые бензиновый и дизельный моторы, которые отличались прекрасной экономичностью. Подвеска передних колес стала независимой, а рулевое управление — реечным. В итоге водитель крупного внедорожника за рулем чувствовал себя как в обычной легковушке. В салоне появился раздельный климат-контроль для передних и задних сидений, мультимедиасистема и прочие элементы, отличающие роскошный автомобиль от обычного.

Toyota Land Cruiser 100 — знаковый автомобиль для российских покупателей в начале нулевых

Удивительно, но благодаря уникальным потребительским свойствам и отменной надежности многие из описанных выше автомобилей еще довольно часто встречаются на дорогах всего мира — в том числе и в России. Более того, на вторичном рынке они ценятся очень высоко — шутка ли, за 15-20-летний Land Cruiser в отличном состоянии порой просят больше, чем за новый кроссовер без пробега!

Но время не стоит на месте — и сейчас бал в семействе внедорожников Toyota правят среднеразмерный внедорожник Land Cruiser Prado серии 150 и флагман — Land Cruiser 200.

Обслуживание


Масляный фильтр
Двигатель Тойота 2UZ-FE, как и любой мотор, нуждается в своевременном техническом обслуживании. В соответствии с регламентом замену масла и масляного фильтра необходимо производить во время каждого ТО (т.е. не реже 10 тыс. км).


Свечи зажигания 8 шт. 2UZ-FE

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


Ремень ГРМ

Ремень ГРМ 2UZ-FE требует обновления при 100 тыс. км, а антифриз в системе охлаждения нужно заменить, когда авто пройдет 150 тысяч км. Помпу лучше менять вместе с ремнем газораспределительного механизма, хотя по регламенту цифры аналогичны замене охлаждающей жидкости.


Антифриз Toyota Super Long Life. Концентрат 1л, артикул 08889-80140 (справа) или уже разведённый 5л, арт. 08889-80072 (слева).

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

У ДВС 2UZ-FE есть слабые места, о которых следует помнить, чтобы не пропустить момент замены исчерпавших ресурс деталей.

Toyota Land Cruiser 300. Зачем владельцам беречь свои пальцы?

Toyota Land Cruiser — из тех автомобилей, которые не нуждаются в дополнительном представлении. Но даже легендарные модели время от времени приходится обновлять. Как изменился и каким стал знаменитый Land Cruiser с выходом нового поколения под индексом 300?

Мировая презентация Land Cruiser 300 прошла 9 июня еще утром. Но в России представительство Тойоты ввело эмбарго на публикацию каких-либо сведений о новинке до позднего вечера. Зато мы можем рассказать больше, чем было озвучено. А главное — мы знаем, каким будет Land Cruiser в российской спецификации. В том числе и на основе первых личных впечатлений. Да-да, мы смогли увидеть и оценить новый Land Cruiser досрочно! Жаль только, что пока лишь в статике и без собственных фотографий: фотоаппараты и даже мобильные телефоны нас перед презентацией попросили сдать…

«Брутальный и уверенный образ флагмана Toyota» — так характеризуют дизайн TLC 300 создатели. В топ-версии «70th Anniversary» (на фото) оптика полностью светодиодная (внедорожная комплектация VX получит «статические» указатели поворота, а в «базе» свет рефлекторный, с лампочками накаливания в «поворотниках»)

Белый автомобиль встретил нас в просторном техническом центре российского представительства Toyota. Дизайн сюрпризом не стал, так как в Сети уже полно «шпионских» фото новинки — в том числе и в различных комплектациях, отличающихся внешне. Белый кузов несколько оттеняет хромированный декор, но зато выделяет новую форму решетки радиатора и переднего бампера. Преемственность — налицо. Но мне кажется, дизайн «трехсотого» в первое время будет вызывать различные мнения и споры. Как, впрочем, было и с TLC 200 14 (!) лет назад…


Стилистические изменения в интерьере — куда глобальнее внешних. Я бы сказал, что Land Cruiser стал в чем-то «рэнджроверным». Но главное — японцы сознательно сохранили физические кнопки и клавиши, считая их более удобными на бездорожье и привычными для своих клиентов

За годы вывода на рынок TLC 200 в мире внедорожников произошло немало изменений: прямой конкурент от Nissan (Nissan Patrol) покинул не только европейский и российский, но даже родной японский рынок (хотя пока еще остался на Ближнем Востоке и в Америке), Mitsubishi завершили выпуск Mitsubishi Pajero, Jeep основным двигателем для Jeep Wrangler сделал 2,0-литровый бензиновый турбомотор, а некогда кондовый и утилитарный Land Rover Defender кардинально сменил идеологию и стал, по сути, самым технологичным из производящихся сегодня автомобилей повышенной проходимости. Land Cruiser же и в новом поколении сохраняет проверенные решения — лонжеронную раму и неразрезной задний мост в сочетании с постоянным полным приводом. Однако теперь в Toyota его позиционируют не как внедорожник, а как вседорожник.


Новая платформа GA-F позволила снизить центр тяжести автомобиля и улучшить развесовку по осям. В конструкции рамы применены цельные элементы из высокопрочной стали (все продольные элементы), соединенные лазерной сваркой. В кузове из все той же высокопрочной стали сделаны стойки и пороги, а передние крылья, двери, крыша и капот теперь алюминиевые. Эти меры позволили увеличить жесткость кузова и рамы TLC 300 на 20%, и на 200 кг снизить вес

Значит ли это, что знаменитый «Крузак» стал более «паркетным»? В Тойоте это отрицают, парируя, что во внедорожной версии модели VX все геометрические параметры сохранены. В частности, угол въезда составляет 32 градуса, съезда — 26,5 градуса, а дорожный просвет равен 230 мм. Привод, как уже говорилось, постоянный полный. А с ним на все той же модификации VX идет три принудительных жестких блокировки. Правда, на двух других комплектациях — топовой «70th Anniversary» и условной «базовой», пока еще не имеющей собственного обозначения, — блокировок меньше: в «топе» их только две (центр + задний LSD-дифференциал), а в «базе» и вовсе одна (межосевая). Также на «внедорожной» версии используется новая система кинетической стабилизации подвески с электронным управлением E-KDSS (в ней теперь два исполнительных элемента на передней оси и один на задней), которая не только борется с кренами на асфальте, но и улучшает артикуляцию подвески на бездорожье. А вот пневмоподвески для Land Cruiser не предусмотрено вовсе. По крайней мере, пока…


В топ-версии «70th Anniversary» вместо E-KDSS используется адаптивная подвеска AVS и система активного управления VDIM. Обновлена и система выбора режимов движения Multi-Terrain Select, которая теперь работает почти бесшумно (владельцы «двухсоток» и Прадо поймут

Двигатель Toyota UZ Википедия

Двигатель 1UZ-FE

1UZ-FE non VVT-i (1989—1997 гг.)


Toyota UZ
Производитель: Toyota Motor Corporation
Марка: Toyota 1UZ-FE
Тип: бензиновый
Объём: 3968 см3
Максимальная мощность: 261 л.с., при 5400 об/мин
Максимальный крутящий момент: 363 Н·м, при 4600 об/мин
Конфигурация: V8
Цилиндров: 8
Клапанов: 32
Ход поршня: 82,5 мм
Диаметр цилиндра: 87,5 мм
Степень сжатия: 10,4
Охлаждение: жидкостное
Клапанной механизм: DOHC
Материал блока цилиндров: алюминиевый сплав
Материал ГБЦ: алюминиевый сплав
Тактность (число тактов): 4
Порядок работы цилиндров: 1-8-4-3-6-5-7-2
Рекомендованное топливо: АИ-95

Базовая версия двигателя серии UZ дебютировал в августе 1989 году на автомобиле Toyota Crown серии S130, а в октябре 1989 года на Lexus LS (Toyota Celsior) первой серии (UCF10). В скором времени он появился на целом ряде других моделей Toyota и Lexus.

Согласно , двигатель получил обозначение 1UZ-FE. В обозначении первая цифра обозначает поколение (1 — первое поколение), буквы за цифрой — семейство (UZ), оставшиеся буквы — исполнение (F — клапанный механизм DOHC с «экономичными» узкими фазами, E — впрыск топлива с электронным управлением).

V-образный двигатель с углом развала 90° имеет диаметр цилиндра 87,5 мм, а ход поршня 82,5 мм. Межцилиндровое расстояние блока цилиндров — 4.15″ (105.41мм), длина шатуна 146 мм. Коленчатый вал имеет пять коренных подшипников скольжения, распределительные валы и помпа приводятся в движение зубчатым ремнём. Коленчатый вал, так же, как и шатуны изготовлен из стали. Поршни выполнены из специального сплава алюминия и кремния. Гидрокомпенсаторы зазора клапанов отсутствуют, зазор регулируется шайбами.

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

В стоковой версии двигателя степень сжатия составила 10:1, мощность 245 л.с., крутящий момент 353 Н·м. Двигатель агрегатировался только с четырёхступенчатой автоматической коробкой передач Aisin серии

В августе 1994 года с конвейера стал сходить несколько доработанный двигатель. Были облегчены шатуны (прежние — 628 г, облегчённые — 581 г), увеличилась степень сжатия до 10,4. Эти доработки позволили поднять мощность до 261 л.с., а крутящий момент до 363 Н·м.

Использование:

  • 1989–1997 Lexus LS 400/Toyota Celsior
  • 1989–1997 Toyota Crown/Toyota Crown Majesta
  • 1991–1997 Lexus SC 400/Toyota Soarer
  • 1992–1997 Lexus GS 400/Toyota Aristo

1UZ-FE VVT-i (1997—2002 гг.)


Toyota UZ
Производитель: Toyota Motor Corporation
Марка: Toyota 1UZ-FE VVT-i
Тип: бензиновый
Объём: 3968 см3
Максимальная мощность: 280 л.с., при 6000 об/мин
Максимальный крутящий момент: 407 Н·м, при 4000 об/мин
Конфигурация: V8
Цилиндров: 8
Клапанов: 32
Ход поршня: 82,5 мм
Диаметр цилиндра: 87,5 мм
Степень сжатия: 10,5
Охлаждение: жидкостное
Клапанной механизм: DOHC
Материал блока цилиндров: алюминиевый сплав
Материал ГБЦ: алюминиевый сплав
Тактность (число тактов): 4
Порядок работы цилиндров: 1-8-4-3-6-5-7-2
Рекомендованное топливо: АИ-95

В июле 1997 стал выпускаться обновлённый 1UZ-FE. Двигатель получил фирменную систему изменения фаз газораспределения Toyota VVT-i («Variable Valve Timing with intelligence»), степень сжатия увеличилась до 10,5. Система зажигания была модернизирована: вместо распределителей зажигания установлены датчики Холла, применены индивидуальные катушки зажигания.

Эти серьёзные изменения подняли мощность до 280 л.с., а крутящий момент до 407 Н·м. После небольшой настройки блока управления, двигатель, установленный на Lexus GS400, показал 300 л.с. и 420 Н·м. Двигатель агрегатировался с новым «умным» пятиступенчатым автоматом.

1UZ-FE с системой VVT-i входил в десятку лучших двигателей по версии «Ward’s AutoWorld magazin» с 1998 по 2000 год.

Использование:

  • 1997–2000 Lexus LS 400/Toyota Celsior
  • 1997–2002 Toyota Crown/Toyota Crown Majesta
  • 1997–2000 Lexus SC 400/Toyota Soarer
  • 1997–2000 Lexus GS 400/Toyota Aristo

Ремонт Toyota Land Cruiser Тойота Ленд Крузер : Двигатель

  1. Руководства по ремонту
  2. Руководство по ремонту Тойота Ленд Крузер 100 1997-2003 г.в.
  3. Двигатель

Двигатель

Спецификации

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

Общие параметры

Характеристика

Значение

Обозначение двигателей

   8–цилиндровый (V8) бензиновый двигатель 4.7 л

2UZ–FE

   6–цилиндровый (R6) турбодизельный двигатель 4.2 л

1HD–FTE

Объем двигателя, л (см3)

   Бензиновый двигатель 2UZ–FE

4.7 (4663)

   Дизельный двигатель 1HD–FTE

4.2 (4164)

Развиваемая мощность и крутящий момент, кВт@мин–1/Нм@мин–1

   Бензиновый двигатель 2UZ–FE

[email protected]/[email protected]

   Дизельный двигатель 1HD–FTE

[email protected]/[email protected] – 3200

Нумерация цилиндров (считая со стороны привода ГРМ) (обратитесь к сопроводительной иллюстрации в Спецификациях к Главе Настройки и текущее обслуживание автомобиля )

   Двигатель 2UZ–FE

      Левый ряд цилиндров

1–3–5–7

      Правый ряд

2–4–6–8

   Двигатель 1HD–FTE

1–2–3–4–5–6

Порядок зажигания

   Двигатель 2UZ–FE

1–8–4–3–6–5–7–2

   Двигатель 1HD–FTE

1–4–2–6–3–5

Степень сжатия

   Двигатель 2UZ–FE

9.6:1

   Двигатель 1HD–FTE

18.8:1

Материал блока цилиндров

Чугун

Материал головки(ок) цилиндров

   Двигатель 2UZ–FE

Алюминий

   Двигатель 1HD–FTE

Чугун

Предельная допустимая неплоскостность

   Двигатель 1HD–FTE

      Головка цилиндров

0.10

      Впускной трубопровод

0.15

      Выпускные коллекторы

0.50

      Блок цилиндров

0.07

Диаметр болтов крепления головок цилиндров двигателя 2UZ–FE на расстоянии 80 мм от их головок, не менее, мм

   Номинальное значение

9.810 ÷ 9.960

   Предельно допустимое значение

9.700

Диаметр растяжимой части болтов крепления крышек подшипников коленчатых валов двигателя 2UZ–FE, не менее, мм

   Номинальное значение

10.760 ÷ 10.970

   Предельно допустимое значение

10.400

Давление масла при 3000 об/мин, бар

   Двигатель 2UZ–FE

3.0 х 6.0

   Двигатель 1HD–FTE

2.5 х 6.1

Диаметр цилиндров х ход поршня, мм

   Двигатель 2UZ–FE

94 х 84

   Двигатель 1HD–FTE

94 х 100

Степень сжатия

   Двигатель 2UZ–FE

9.6:1

   Двигатель 1HD–FTE

18.8:1

Распределительные валы и сопутствующие компоненты

Характеристика

Значение

Диаметр подшипниковых шеек, мм

   2UZ–FE

26.954 ÷ 26.970

   1HD–FTE

      Шейка №1

34.969 ÷ 34.985

      Остальные шейки

27.986 ÷ 27.998

Зазоры в подшипниках, мм

   2UZ–FE

      Номинальное значение

0.030 ÷ 0.067

      Предельно допустимое значение

0.10

   1HD–FTE

      Номинальное значение

         Шейка №1

0.022 ÷ 0.074

         Остальные шейки

0.023 ÷ 0.075

      Предельно допустимое значение

0.100

Высота кулачков, мм

   2UZ–FE

      Номинальное значение

         Кулачки привода впускных клапанов

41.94 ÷42.04

         Кулачки привода выпускных клапанов

41.96 ÷ 42.06

      Предельно допустимое значение

         Кулачки привода впускных клапанов

41.79

         Кулачки привода выпускных клапанов

41.91

   1HD–FTE

      Номинальное значение

         Кулачки привода впускных клапанов

48.498 ÷ 48.598

         Кулачки привода выпускных клапанов

50.734 ÷ 50.834

      Предельно допустимое значение

         Кулачки привода впускных клапанов

47.998

         Кулачки привода выпускных клапанов

50.234

Величина осевого люфта, мм

   2UZ–FE

      Номинальное значение

         Впускной вал

0.040 ÷ 0.090

         Выпускной вал

0.040 ÷ 0.085

      Предельно допустимое значение

0.12

   1HD–FTE

      Номинальное значение

0.10 ÷ 0.20

      Предельно допустимое значение

0.30

Люфт зацепления шестерен распределительных валов, мм

   2UZ–FE

      Номинальное значение

0.020 ÷ 0.200

      Предельно допустимое значение

0.30

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

   2UZ–FE

18.2 ÷ 18.8

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

   2UZ–FE

0.08

   1HD–FTE

0.10

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

   2UZ–FE

10.5 ÷ 11.5

   1HD–FTE

9.0 ÷ 9.8

Параметры гидротолкателей клапанов, мм

   2UZ–FE

      Наружный диаметр

30.966 ÷ 30.976

      Диаметр посадочного гнезда

31.000 ÷ 31.016

      Посадочный зазор

         Номинальное значение

0.024 ÷ 0.050

         Предельное допустимое значение

0.07

   1HD–FTE

      Наружный диаметр

40.892 ÷ 40.902

      Диаметр посадочного гнезда

40.960 ÷ 40.980

      Посадочный зазор

         Номинальное значение

0.058 ÷ 0.083

         Предельное допустимое значение

0.10

Усилия затягивания резьбовых соединений, Нм

Бензиновый двигатель (2UZ–FE)

Тип соединения

Значение

Болты крепления крышек головок цилиндров

6

Болты/гайки крепления впускного трубопровода

18

Гайки крепления выпускных коллекторов

44

Гайки крепления приемной трубы к коллектору

62

Болты крепления теплозащитного экрана

7.5

Болт крепления шкива коленчатого вала

245

Болты крепления крышки №2 привода ГРМ

16

Болты крепления крышки №3 привода ГРМ

7.5

Болты крепления промежуточных роликов*

35

Болт (106 мм) и гайки крепления натяжителя приводного ремня

16

Болты крепления натяжителя газораспределительного ремня

26

Болты крепления зубчатых колес распределительных валов

108

Болты крепления кронштейна вентилятора

   Болты 12 мм

16

   Болты 14 мм

32

Болты крепления крышек подшипников распределительных валов

   Болты 25 мм

7.5

   Остальные болты

16

Болты крепления головок цилиндров

   Стадия 1

32

   Стадия 2

Дотянуть еще на 90 град.

   Стадия 3

Дотянуть еще на 90 град.

Болты крепления верхней части поддона картера

   Болты 10 мм

7.5

   Болты 12 мм

28

Болты крепления верхней части поддона картера

7.5

Болты крепления маслозаборника

7.5

Болты крепления демпфирующей пластины

7.5

Стяжные болты масляного насоса

10

Болты крепления масляного насоса

   Болты 14 мм

30

   Остальные болты

15

Болты крепления насоса ГУР

17

Крепеж маслоохладителя

18

Болты крепления маховика*

83

Болты крепления приводного диска*

   Стадия 1

49

   Стадия 2

Дотянуть еще на 90 град.

Опоры подвески двигателя

   Болты крепления держателя заднего сальника коленчатого вала

7.8

* Перед вворачиванием болта его резьбовую часть следует смазать фиксирующим герметиком Loctite 242.

Дизельный двигатель (1HD–FTE)

Тип соединения

Значение

Болты крепления головки цилиндров

   Стадия 1

69

   Стадия 2

Дотянуть еще на 90 град.

   Стадия 3

Дотянуть еще на 90 град.

Болты крепления крышек подшипников распределительных валов

25

Болты крепления задней крышки ремня привода ГРМ

20

Болты крепления крышек головок цилиндров

6.5

Крепеж заднего кронштейна двигателя

39

Болты крепления сборки выпускного коллектора

40

Болты крепления патрубка отвода ОЖ

20

Гайки крепления впускного трубопровода

20

Крепеж топливных трубок высокого давления

25

Крепеж впускного патрубка к впускному трубопроводу

   Модели с системой EGR

19.6

   Модели без системы EGR

      С головками 10 мм

7.5

      С головками 12 мм

20

Гайки крепления адаптера клапана EGR к выпускному коллектору

40

Болты крепления кронштейна клапана EGR

20

Болты крепления нижней крышки шатуна

   Стадия 1

37

   Стадия 2

Дотянуть еще на 90 град.

Болты крепления крышек коренных подшипников коленчатого вала

   Стадия 1

103

   Стадия 2

Дотянуть еще на 90 град.

Зубчатое колесо распределительного вала

   Ведомое

98

   Ведущее

31

Шестерня привода ТНВД

98

Промежуточная шестерня

68

Шкив коленчатого вала

430

Болты крепления крышки зубчатых колес

20

Гайки крепления крышки масляного насоса

39

Болты крепления маслопровода

20

Пробка редукционного клапана масляного насоса

42

Заливная пробка масляного насоса

9

Обратный клапан маслоохладителя

27

Предохранительный клапан маслоохладителя

39

Гайки крепления крышки маслоохладителя

20

Крепеж маслоохладителя

20

Процедуры общего и капитального ремонта двигателя (бензиновый двигатель 2UZ–FE)

Общие параметры

Характеристика

Значение

Компрессионное давление в цилиндрах при 250 об/мин, кГс/см2

   Номинальное значение

13.44

   Минимальное допустимое значение

9.94

Допустимая разница компрессионного давления в разных цилиндрах при 250 об/мин, кГс/см2

не более 0.98

Клапанный механизм

Характеристика

Значение

Высота цилиндрической части (пояска) тарелок клапанов, мм

   Номинальное значение

      Впускные клапаны

1.25

      Выпускные клапаны

1.4

   Предельное допустимое значение

0.5

Диаметр стержней клапанов, мм

   Впускные клапаны

5.470 ÷ 5.485

   Выпускные клапаны

5.465 ÷ 5.480

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

   Впускные клапаны

      Номинальное значение

0.025 ÷ 0.060

      Предельное допустимое значение

0.08

   Выпускные клапаны

      Номинальное значение

0.030 ÷ 0.065

      Предельное допустимое значение

0.10

Фаска клапана, град

44.5

Полная длина клапана, мм

   Впускные клапаны

      Номинальное значение 95.05

Коренные шейки коленчатого вала

   Диаметр постели коленчатого вала, мм

      Метка «1»

71.000 ÷ 71.003

      Метка «2»

71.006 ÷ 71.012

      Метка «3»

71.012 ÷ 71.018

   Диаметр коренных шеек, мм

      Метка «1»

66.994 ÷ 67.000

      Метка «2»

66.988 ÷ 66.994

      Метка «3»

66.982 ÷ 66.988

   Толщина вкладышей коренных подшипников, мм

      Метка «2»

1.979 ÷ 1.982

      Метка «3»

1.982 ÷ 1.985

      Метка «4»

1.985 ÷ 1.988

      Метка «5»

1.988 ÷ 1.991

      Метка «6»

1.991 ÷ 1.994

   Рабочий зазор в подшипниках, мм

      Номинальное значение

0.036 ÷ 0.054

      Ремонтный размер

0.037 ÷ 0.077

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

0.100

Осевой люфт коленчатого вала, мм

      Номинальное значение

0.040 ÷ 0.240

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

0.30

Толщина ремонтного упорного подшипника, мм

2.930 ÷ 2.980

Блок и головка цилиндров

Характеристика

Значение

Диаметр цилиндра, мм

   Номинальный

      Метка «1»

94.000 ÷ 94.010

      Метка «2»

94.010 ÷ 94.020

      Метка «3»

94.020 ÷ 94.030

   Допустимый

      До 1–го ремонта

94.23

      До 2–го ремонта

94.73

Диаметр сверления под направляющую втулку клапана, мм

   Номинальный

11.504 ÷ 11.525

   Ремонтный

11.554 ÷ 11.575

Внутренний диаметр направляющей втулки, мм

7.010 ÷ 7.030

Выступ втулки, мм

17.5 ÷ 17.9

Поршни и поршневые кольца

Характеристика

Значение

Диаметр поршня (номинальное значение), мм

   Метка «1»

93.845 ÷ 93.855

   Метка «2»

93.855 ÷ 93.865

   Метка «3»

93.865 ÷ 93.875

Выступ поршня из блока цилиндров, мм

0.175 ÷ 0.425

Зазор посадки поршней в цилиндрах, мм

   Номинальное значение

0.145 ÷ 0.165

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

0.215

Зазоры в замках поршневых колец, мм

   Верхнее компрессионное кольцо

      Номинальное значение

0.27 ÷ 0.47

      Предельное допустимое значение

0.85

   Второе компрессионное кольцо

      Номинальное значение

0.40 ÷ 0.65

      Предельное допустимое значение

0.90

   Маслосъемное кольцо

      Номинальное значение

0.20 ÷ 0.50

      Предельное допустимое значение

0.88

Зазоры посадки колец в канавках поршней, мм

   Верхнее компрессионное кольцо

0.050 ÷ 0.095

   Второе компрессионное кольцо

0.050 ÷ 0.100

   Маслосъемное кольцо

0.030 ÷ 0.070

   Максимально допустимый зазор

0.20


Скачать информацию со страницы
↓ Комментарии ↓

 



1. Введение
1.0 Введение 1.2 Идентификационные номера автомобиля 1.3 Приобретение запасных частей 1.4 Технология обслуживания, инструмент и оборудование рабочего места 1.5 Поддомкрачивание и буксировка 1.6 Запуск двигателя от вспомогательного источника питания 1.7 Автомобильные химикалии, очистители, герметики 1.8 Диагностика неисправностей узлов и систем автомобиля

2. Органы управления и приемы безопасной эксплуатации автомобиля
2.0 Органы управления и приемы безопасной эксплуатации автомобиля 2.1 Спецификации 2.2 Приборный щиток и сигнальные устройства 2.3 Отпирание и запирание замков автомобиля, управление стеклоподъемниками 2.4 Переключатели 2.5 Замок зажигания, трансмиссия и темпостат 2.6 Системы вентиляции, отопления и кондиционирования воздуха 2.7 Аудиосистема

3. Настройки и текущее обслуживание автомобиля
3.0 Настройки и текущее обслуживание автомобиля 3.1 Спецификации 3.2 График текущего обслуживания 3.3 Общие сведения о настройках и регулировках 3.4 Проверка уровней жидкостей 3.5 Проверка состояния шин и давления их накачки 3.6 Проверка уровня рабочей жидкости АТ 3.7 Проверка уровня жидкости гидроусилителя руля 3.8 Замена двигательного масла и масляного фильтра 3.9 Проверка, обслуживание и зарядка аккумуляторной батареи 3.10 Проверка состояния компонентов системы охлаждения 3.11 Проверка состояния и замена расположенных в двигательном отсеке шлангов 3.12 Проверка состояния и замена щеток стеклоочистителей 3.13 Ротация колес 3.14 Проверка состояния компонентов подвески и рулевого привода 3.15 Смазывание компонентов шасси 3.16 Проверка состояния компонентов системы выпуска отработавших газов 3.17 Проверка уровня смазки в раздаточной коробке 3.18 Проверка уровня смазки дифференциала 3.19 Проверка состояния ремней безопасности 3.20 Проверка и регулировка оборотов холостого хода 3.21 Проверка состояния защитных чехлов приводных валов 3.22 Проверка и замена клапана системы управляемой вентиляции картера (PCV) 3.23 Замена фильтрующего элемента воздухоочистителя 3.24 Проверка состояния, регулировка усилия натяжения и замена приводных ремней 3.25 Проверка состояния компонентов системы питания 3.26 Проверка тормозной системы 3.27 Регулировка высоты положения и свободного хода педали тормоза 3.28 Проверка состояния и замена свечей зажигания (бензиновые двигатели) 3.29 Проверка и регулировка зазоров клапанов 3.30 Замена топливного фильтра 3.31 Проверка и обслуживание кондиционера воздуха (К/В) 3.32 Обслуживание системы охлаждения 3.33 Проверка состояния, набивка смазкой и регулировка передних ступиц и колесных подшипников 3.34 Замена ATF автоматической трансмиссии и главной передачи 3.35 Замена смазки раздаточной коробки 3.36 Замена смазки дифференциала 3.37 Проверка состояния компонентов системы улавливания топливных испарений 3.38 Проверка исправности состояния компонентов системы рециркуляции отработавших газов (EGR)

4. Двигатель
4.0 Двигатель 4.1. Типичные процедуры обслуживания двигателей 4.2. Процедуры обслуживания бензинового двигателя 4.3. Процедуры обслуживания дизельного двигателя

5. Системы охлаждения двигателя, отопления салона и кондиционирования воздуха
5.0 Системы охлаждения двигателя, отопления салона и кондиционирования воздуха 5.1 Спецификации 5.2 Антифриз – общие сведения 5.3 Проверка исправности функционирования и замена термостата 5.4 Проверка состояния, снятие и установка вентилятора системы охлаждения 5.5 Снятие и установка радиатора и расширительного бачка системы охлаждения 5.6 Проверка состояния водяного насоса 5.7 Снятие и установка водяного насоса 5.8 Проверка исправности функционирования и замена блока датчика измерителя температуры охлаждающей жидкости 5.9 Проверка исправности функционирования приводного электромотора вентилятора отопителя и его замена 5.10 Снятие и установка блока и теплообменника отопителя 5.11 Снятие и установка сборки панели управления функционированием отопителя и кондиционера воздуха 5.12 Проверка исправности функционирования и обслуживание систем отопления и кондиционирования воздуха

6. Системы питания и выпуска отработавших газов
6.0 Системы питания и выпуска отработавших газов 6.1 Спецификации 6.2 Сбрасывание давления в системе питания 6.3 Проверка исправности функционирования топливного насоса, измерение давления топлива 6.4 Проверка состояния и замена топливных линий и их штуцерных соединений 6.5 Снятие и установка топливного бака 6.6 Чистка и ремонт топливного бака – общие сведения 6.7 Снятие и установка топливного насоса 6.8 Замена датчика расхода топлива 6.9 Снятие и установка сборки воздухоочистителя 6.10 Снятие, установка и регулировка троса акселератора 6.11 Система электронного впрыска топлива (EFI) – общая информация 6.12 Проверка исправности функционирования системы электронного впрыска 6.13 Проверка состояния и замена компонентов системы впрыска 6.14 Система выпуска – общая информация 6.15 Снятие и установка форсунок

7. Электрооборудование двигателя
7.0 Электрооборудование двигателя 7.1 Спецификации 7.2 Запуск двигателя от вспомогательного источника питания 7.3 Снятие и установка аккумуляторной батареи 7.4 Проверка состояния и замена проводов батареи 7.5 Система зажигания – общая информация и меры предосторожности (бензиновые модели) 7.6 Проверка функционирования системы зажигания 7.7 Замена катушки зажигания 7.8 Проверка и регулировка установки угла опережения зажигания/впрыска топлива бензинового двигателя 7.9 Замена модуля зажигания 7.10 Система заряда – общая информация и меры предосторожности 7.11 Проверка состояния системы заряда 7.12 Снятие и установка генератора 7.13 Проверка состояния и замена компонентов генератора 7.14 Система запуска – общая информация и меры предосторожности 7.15 Проверка исправности функционирования стартера и цепи запуска 7.16 Снятие и установка стартера 7.17 Снятие и установка тягового реле

8. Системы управления двигателем и снижения токсичности отработавших газов
8.0 Системы управления двигателем и снижения токсичности отработавших газов 8.1 Спецификации 8.2 Система бортовой диагностики (OBD) – ринцип функционирования и коды неисправностей 8.3 Применение осциллографа для наблюдения рабочих сигналов системы управления 8.4 Проверка состояния и замена ЕСМ 8.5 Информационные датчики – общая информация и проверка исправности функционирования 8.6 Замена информационных датчиков 8.7 Система улавливания топливных испарений (EVAP) – общая информация, проверка состояния и замена компонентов 8.8 Система управляемой вентиляции картера (PCV) 8.9 Каталитический преобразователь – общая информация, проверка состояния и замена

9. Коробка переключения передач
9.0 Коробка переключения передач 9.1. Автоматическая трансмиссия (АТ) 9.2. Раздаточная коробка

10. Трансмиссионная линия
10.0 Трансмиссионная линия 10.1 Спецификации 10.2 Карданные валы и шарниры – общая информация 10.3 Проверка состояния трансмиссионной линии 10.4 Снятие и установка карданного вала 10.5 Замена карданных шарниров 10.6 Приводные валы/полуоси, общая информация и проверка состояния 10.7 Снятие и установка полуосей, подшипников и сальников заднего моста 10.8 Замена сальника ведущей шестерни дифференциала 10.9 Снятие и установка сборки заднего моста 10.10 Снятие и установка приводных валов 10.11 Замена защитных чехлов и обслуживание ШРУСов 10.12 Снятие и установка сборки переднего дифференциала 10.13 Снятие и установка ступиц с отключаемым приводом

11. Тормозная система
11.0 Тормозная система 11.1 Спецификации 11.2 Система антиблокировки тормозов (ABS) – общая информация и коды неисправностей 11.3 Замена тормозных колодок 11.4 Снятие и установка суппортов дисковых тормозных механизмов 11.5 Проверка состояния, снятие и установка тормозного диска 11.6 Снятие и установка главного тормозного цилиндра (ГТЦ) 11.7 Проверка состояния и замена тормозных линий и шлангов 11.8 Чувствительный к загрузке/перепускной клапан (LSP & BP) 11.9 Регулировка стояночного тормоза 11.10 Замена тросов привода стояночного тормоза 11.11 Проверка исправности функционирования/ герметичности, снятие и установка усилителя тормозов 11.12 Прокачка тормозной системы 11.13 Регулировка педали ножного тормоза 11.14 Проверка исправности функционирования и замена датчика-выключателя стоп-сигналов 11.15 Датчики и активатор системы ABS

12. Подвеска и рулевое управление
12.0 Подвеска и рулевое управление 12.1 Спецификации 12.2 Снятие и установка передних амортизаторов 12.3 Снятие и установка переднего стабилизатора поперечной устойчивости 12.4 Снятие и установка сборки поворотного кулака со ступицей 12.5 Проверка состояния и замена шаровых опор 12.6 Снятие и установка торсионных штанг 12.7 Снятие и установка верхнего управляющего рычага передней подвески 12.8 Снятие и установка нижнего управляющего рычага передней подвески 12.9 Снятие и установка задних амортизаторов 12.10 Снятие и установка штанги заднего стабилизатора поперечной устойчивости 12.11 Снятие и установка реактивной штанги 12.12 Снятие и установка винтовой пружины задней подвески 12.13 Снятие и установка рычагов задней подвески 12.14 Снятие и установка рулевого колеса 12.15 Проверка состояния, снятие и установка тяг рулевого привода 12.16 Замена защитных чехлов сборки рулевого механизма 12.17 Снятие и установка рулевого механизма 12.18 Снятие и установка рулевого насоса 12.19 Удаление воздуха из гидравлического тракта системы усиления руля 12.20 Колеса и шины – общая информация 12.21 Углы установки колес

13. Кузов
13.0 Кузов 13.1 Спецификации 13.2 Уход за компонентами кузова и днища автомобиля 13.3 Уход за виниловыми элементами отделки 13.4 Уход за обивкой и ковровыми покрытиями салона 13.5 Ремонт незначительных повреждений кузовных панелей 13.6 Ремонт серьезно поврежденных кузовных панелей 13.7 Обслуживание петель и замков автомобиля 13.8 Замена ветрового и других фиксированных стекол 13.9 Снятие, установка и регулировка положения капота 13.10 Снятие и установка защелки замка капота и троса ее привода 13.11 Снятие и установка декоративной решетки радиатора 13.12 Снятие и установка переднего и заднего бамперов 13.13 Снятие и установка панелей внутренней обивки дверей 13.14 Снятие и установка наружных зеркал заднего вида 13.15 Снятие, установка и регулировка дверей 13.16 Снятие и установка передних крыльев 13.17 Снятие, установка и регулировка двери задка 13.18 Снятие и установка стекла и регулятора стеклоподъемника двери задка 13.19 Снятие и установка дверных стекол 13.20 Снятие и установка регуляторов стеклоподъемников 13.21 Снятие и установка защелок, замковых цилиндров и дверных ручек 13.22 Снятие и установка крышки верхнего люка с приводом 13.23 Снятие и установка кожуха рулевой колонки 13.24 Снятие и установка центральной консоли 13.25 Снятие и установка отделочных и главной секций панели приборов 13.26 Снятие и установка решетки воздухозаборника переднего обтекателя 13.27 Снятие и установка сидений 13.28 Снятие и установка внутреннего зеркала заднего вида

14. Бортовое электрооборудование
14.0 Бортовое электрооборудование 14.1 Поиск причин отказов электрооборудования 14.2 Предохранители – общая информация 14.3 Плавкие вставки – общая информация 14.4 Прерыватели цепи – общая информация 14.5 Реле – общая информация и проверка исправности функционирования 14.6 Цифровая шина данных CAN 14.7 Проверка исправности функционирования и замена прерывателя указателей поворотов/аварийной сигнализации и выключателя последней 14.8 Замена переключателя указателей поворота/переключателя режимов функционирования наружных осветительных приборов 14.9 Замена выключателя зажигания и замка блокировки рулевой колонки 14.10 Проверка исправности функционирования и замена переключателя режимов функционирования очистителей ветрового стекла 14.11 Замена ламп головных фар 14.12 Регулировка направления оптических осей головных фар 14.13 Снятие и установка блок-фар 14.14 Замена ламп 14.15 Снятие и установка аудиосистемы и ее динамиков 14.16 Снятие и установка антенны радиоприемника 14.17 Проверка исправности функционирования, замена электромотора привода стеклоочистителей и насоса омывателей 14.18 Проверка исправности функционирования и замена выключателя обогрева заднего стекла 14.19 Проверка исправности функционирования и восстановительный ремонт обогревателя заднего стекла 14.20 Снятие и установка комбинации приборов 14.21 Проверка исправности функционирования и замена рожков клаксона 14.22 Электропривод наружных зеркал заднего вида – общие сведения и проверка исправности функционирования 14.23 Система управления скоростью (темпостат) – общие сведения, проверка исправности функционирования компонентов 14.24 Электропривод стеклоподъемников – общие сведения и проверка исправности функционирования 14.25 Единый замок и система дистанционного управления дверными активаторами – общие сведения и проверка исправности функционирования 14.26 Ходовые огни светлого времени суток (DRL) 14.27 Подушки безопасности – общая информация 14.28. Схемы электрических соединений – общая информация

Стандартная архитектура кластера  | Документация по ядру Kubernetes  | Облако Google


Кластер является основой Google Kubernetes Engine (GKE): Kubernetes все объекты, представляющие ваши контейнерные приложения, выполняются поверх кластер.

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

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

Плоскость управления

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

Плоскость управления и Kubernetes API

Плоскость управления — это единая конечная точка для вашего кластера. Вы взаимодействуете с кластером через вызовы API Kubernetes, а плоскость управления запускается процесс Kubernetes API Server для обработки этих запросов. Ты можешь сделать Kubernetes API вызывает напрямую через HTTP/gRPC или косвенно, запуская команды из клиента командной строки Kubernetes ( kubectl ) или путем взаимодействия с пользовательским интерфейсом в облачной консоли.

Процесс сервера API является центром всех коммуникаций для кластера.Все внутренние процессы кластера (такие как узлы кластера, система и компоненты, контроллеры приложений) действуют как клиенты сервера API; сервер API единый «источник истины» для всего кластера.

Взаимодействие плоскости управления и узла

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

Плоскость управления и узлы взаимодействуют с помощью API Kubernetes.

Взаимодействие плоскости управления с реестром артефактов и реестром контейнеров

При создании или обновлении кластера образы контейнеров для Kubernetes программное обеспечение, работающее на уровне управления (и узлах), извлекается из pkg.dev Реестр артефактов или реестр контейнеров gcr.io . Сбой, затрагивающий эти реестры могут вызывать следующие типы сбоев:

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

В случае регионального сбоя реестра артефактов pkg.dev или gcr.io Container Registry, Google может перенаправлять запросы в не затронутую зону или регион по отключению.

Чтобы проверить текущий статус сервисов Google Cloud, перейдите на Панель состояния Google Cloud.

Узлы

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

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

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

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

Узловая машина типа

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

образы операционной системы узла

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

Минимальная платформа ЦП

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

Распределяемые ресурсы узла

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

Поскольку более крупные типы машин, как правило, используют больше контейнеров (и, соответственно, больше Pods), количество ресурсов, которые GKE резервирует для Компоненты Kubernetes расширяются для больших машин. Узлы Windows Server также требуют больше ресурсов, чем обычный узел Linux. Узлы нуждаются в дополнительном ресурсы для работы ОС Windows и для Windows Server компоненты, которые не могут работать в контейнерах.

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

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

  kubectl описать узел  NODE_NAME  | grep Распределяемый -B 7 -A 6
  

Возвращенный вывод содержит Емкость и Распределяемых полей с измерения временной памяти, памяти и ЦП.

Порог вытеснения

Чтобы определить, сколько памяти доступно для модулей, необходимо также учитывать порог выселения. GKE резервирует дополнительно 100 МБ памяти на каждом узле для кубелет выселение.

Выделяемая память и ресурсы ЦП

Распределяемые ресурсы рассчитываются следующим образом:

РАЗМЕЩАЕМЫЙ = МОЩНОСТЬ - ЗАРЕЗЕРВИРОВАНО - ПОРОГ ВЫСЕЛЕНИЯ

Для ресурсов памяти GKE резервирует следующее:

  • 255 МБ памяти для машин с объемом памяти менее 1 ГБ
  • 25% первых 4 ГБ памяти
  • 20% следующих 4 ГБ памяти (до 8 ГБ)
  • 10% следующих 8 ГБ памяти (до 16 ГБ)
  • 6% следующих 112 ГиБ памяти (до 128 ГиБ)
  • 2% любой памяти выше 128 ГиБ

Для ресурсов ЦП GKE резервирует следующее:

  • 6% первого ядра
  • 1% следующего ядра (до 2-х ядер)
  • 0.5% следующих 2 ядер (до 4 ядер)
  • 0,25% любых ядер более 4 ядер

Выделяемые локальные временные ресурсы хранения

Бета

На эту функцию распространяются условия предложений Pre-GA. Условия использования Google Cloud. Функции Pre-GA могут иметь ограниченную поддержку, и изменения в функциях до GA могут быть несовместимы с другими версиями до GA.Для получения дополнительной информации см. описания этапов запуска.

Начиная с GKE версии 1.10, вы можете управлять своим локальным эфемерные ресурсы хранения, так же как и ресурсы процессора и памяти. Учиться как заставить ваши поды указывать запросы и лимиты эфемерного хранилища и видеть как на них действуют, см. Локальное временное хранилище в документации Kubernetes.

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

Объем файловой системы, зарезервированный для kubelet и других системных компонентов дано:

ПОРОГ ВЫСЕЛЕНИЯ + СИСТЕМА-БРОНИРОВАНИЕ

Эфемерное хранилище, поддерживаемое загрузочным диском

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

ПОРОГ ВЫСЕЛЕНИЯ = 10% * ОБЪЕМ ЗАГРУЗОЧНОГО ДИСКА

СИСТЕМА-РЕЗЕРВИРОВАНИЕ = Мин.(50% * ЕМКОСТЬ ЗАГРУЗОЧНОГО ДИСКА , 6 ГБ + 35% * ЕМКОСТЬ ЗАГРУЗОЧНОГО ДИСКА , 100 ГБ)

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

Эфемерное хранилище, поддерживаемое локальными твердотельными накопителями

Зарезервированное пространство системы зависит от количества локальных SSD:

Количество локальные твердотельные накопители СИСТЕМА-БРОНИРОВАНИЕ (ГБ)
1 50
2 75
3 или более 100

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

ПОРОГ ВЫСЕЛЕНИЯ = 10% * NUM-LOCAL-SSDS * 375 ГБ

Емкость каждого локального SSD составляет 375 ГБ.Чтобы узнать больше, см. Документация Compute Engine по добавлению локальных твердотельных накопителей.

Создание зонального кластера  | Документация по ядру Kubernetes  | Облако Google


В этом разделе показано, как создать стандартный зональный кластер с функциями по умолчанию, включенными в Google Kubernetes Engine (GKE). Зональные кластеры иметь одну плоскость управления в одной зоне. В зависимости от ваших требований к доступности вы можете выбрать узлы для вашего зонального кластера в одной зоне или в нескольких зонах.

Подробнее о типы кластеров, которые вы можете Создайте.

Однозонный или многозонный

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

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

Примечание: После создания кластера его нельзя изменить с зонального на региональный. или от региональных до зональных.

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

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

  • Убедитесь, что вы включили API Google Kubernetes Engine.
  • Включить API Google Kubernetes Engine
  • Убедитесь, что вы установили интерфейс командной строки Google Cloud.
  • Настройте параметры интерфейса командной строки Google Cloud по умолчанию для своего проекта одним из следующих способов:
    • Используйте gcloud init , если хотите прошел через настройку проекта по умолчанию.
    • Используйте gcloud config для индивидуального установите идентификатор проекта, зону и регион.

    инициализация gcloud

    1. Запустите gcloud init и следуйте инструкциям:

       инициализация gcloud 

      Если вы используете SSH на удаленном сервере, используйте --console-only флаг, чтобы команда не запускала браузер:

       gcloud init --console-only 
    2. Следуйте инструкциям, чтобы авторизовать интерфейс командной строки gcloud для использования вашего Облачный аккаунт Google.
    3. Создайте новую конфигурацию или выберите существующую.
    4. Выберите проект Google Cloud.
    5. Выберите зону Compute Engine по умолчанию.
    6. Выберите регион Compute Engine по умолчанию.
    Примечание: Вы можете переопределить эти настройки по умолчанию в gcloud CLI с помощью --project , --zone и --флаги региона .

    конфигурация gcloud

    1. Установите идентификатор проекта по умолчанию:
       проект конфигурации gcloud  PROJECT_ID  
    2. Установите регион Compute Engine по умолчанию (например, us-central1 ):
       набор конфигурации gcloud вычисление/регион  COMPUTE_REGION  
    3. Установите зону Compute Engine по умолчанию (например, us-central1-c ):
       набор конфигурации gcloud вычисление/зона  COMPUTE_ZONE  
    4. Обновите gcloud до последней версии:
       обновление компонентов gcloud 
    Примечание: Вы можете переопределить эти настройки по умолчанию в gcloud CLI с помощью --project , --zone и --флаги региона .

    Установив местоположения по умолчанию, вы можете избежать ошибок в gcloud CLI, таких как следующее: Должен быть указан один из [--zone, --region]: Укажите местоположение .

  • Многозональные кластеры используют больше ресурсов, чем однозонные. Если вы создаете многозональный кластер, убедитесь, что у вас достаточно квоты.
  • Убедитесь, что у вас есть правильное разрешение на создание кластеров. Как минимум, вы должен быть администратором кластера Kubernetes Engine.
Важно: Новые кластеры имеют флаг с поддержкой cos-metrics-enabled по умолчанию. Этот параметр позволяет собирать журналы сбоев ядра с помощью dmesg. Отчет не включает журналы пользователей и не собирает персональные данные намеренно. Это потенциально может включать пользовательские журналы, если вы пишете журналы из привилегированного контейнера и привяжите mount /dev/kmsg. И некоторые PII, например, имя процесса, могут появиться в отчете, если ядро ​​включает их в сообщения об ошибках, например, OOM kills. Предупреждение: Если у вас есть политика ограничения ограничения/compute.vmExternalIpAccess, настроенная на Запретить все или на ограничение внешних IP-адресов определенными экземплярами виртуальных машин на уровне организации, папки или проекта, где вы пытаетесь создать общедоступный кластер GKE , то ваши операции по созданию кластера завершатся сбоем. Для получения подробной информации см. информацию об устранении неполадок.

Создать зональный кластер

Вы можете создать зональный кластер с помощью интерфейса командной строки gcloud или Облачная консоль Google.

Если вы разрабатываете приложения GKE с Visual Studio Code, попробуйте создать кластеры с помощью Cloud Code.

gcloud

Чтобы создать зональный кластер с помощью интерфейса командной строки gcloud , используйте один из следующих команд.

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

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

  • CLUSTER_NAME : имя вашего нового кластера.
  • КАНАЛ : тип канала выпуска, который может быть одним из быстрых , обычных , стабильных или None . По умолчанию, кластер зарегистрирован в стандартном канале выпуска , если выполняются следующие условия. флаги не указаны: --cluster-version , --release-channel , --no-enable-autoupgrade и --no-enable-autorepair .
  • COMPUTE_ZONE : вычислительная зона для плоскости управления кластером.
  • ВЕРСИЯ : версия вы хотите указать для своего кластера.
  • COMPUTE_ZONE , COMPUTE_ZONE1 ,[...] : зоны, в которых создаются узлы. Вы можете указать столько зон, сколько необходимо для вашего кластера. Все зоны должны находиться в том же регионе, что и плоскость управления кластера, указанная флагом --zone . Для зональных кластеров --node-locations должен содержать основную зону кластера.

В следующих командах можно дополнительно использовать --service-account= SERVICE_ACCOUNT_NAME @ PROJECT_ID .iam.gserviceaccount.com флаг, чтобы указать другую учетную запись службы IAM, которая в первом пуле узлов вашего кластера вместо Compute Engine учетная запись службы по умолчанию. Этот флаг не является обязательным, но мы настоятельно рекомендуем что вы создаете и используете учетную запись службы с минимальными привилегиями чтобы у ваших узлов не было дополнительных привилегий, которые им требуются.

Использование определенного канала выпуска:

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

кластеры контейнеров gcloud создают  CLUSTER_NAME  \
      --релиз-канал  КАНАЛ  \ 
    --zone  COMPUTE_ZONE  \
    --node-locations  COMPUTE_ZONE  ,  COMPUTE_ZONE1 
 

Использование определенной версии:

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

кластеры контейнеров gcloud создают  CLUSTER_NAME  \
      --cluster-version  ВЕРСИЯ   \
    --zone  COMPUTE_ZONE  \
    --node-locations  COMPUTE_ZONE  ,  COMPUTE_ZONE1 
 
Примечание: Если вы укажете версию кластера, кластер будет использовать именно эту версию. версия и , а не зарегистрированы в канале выпуска.

Использование статической версии по умолчанию:

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

кластеры контейнеров gcloud создают  CLUSTER_NAME  \
      --release-channel Нет \ 
    --zone  COMPUTE_ZONE  \
    --node-locations  COMPUTE_ZONE  ,  COMPUTE_ZONE1 
 

Пример

Следующая команда создает многозональный кластер с именем example-cluster , где плоскость управления кластером расположена в зоне us-central-a , и есть три местоположения узла.Кластер зарегистрирован в обычном выпускной канал.

Когда --num-nodes флаг опущен, количество узлов по умолчанию для каждой зоны, созданных кластером это три. Поскольку были указаны три зоны, эта команда создает кластер из девяти узлов по три узла в каждом us-central1-a , us-central1-b , и us-central1-c .

кластеры контейнеров gcloud создают пример-кластер \
    --zone us-central1-a \
    --node-locations us-central1-a, us-central1-b, us-central1-c
 

Консоль

Чтобы создать зональный кластер с помощью Google Cloud Console, выполните следующие действия. задач:

  1. Перейдите на страницу Google Kubernetes Engine в Cloud Console.

    Перейти к Google Kubernetes Engine

  2. Нажмите Создать .

  3. В разделе Основные сведения о кластере выполните следующие действия:

    1. Введите Имя для вашего кластера.
    2. Для типа местоположения выберите Зональный , а затем выберите желаемая зона для вашего кластер.
    3. Если вы создаете многозональный кластер, выберите Укажите расположение узлов по умолчанию Установите флажок, а затем выберите дополнительные зоны, в которых вы хотите запускать пулы узлов.
    4. Выберите версию плоскости управления . По умолчанию рекомендуемый вариант Канал выпуска . Если вы должны указать статическую версию, убедитесь, что автоматическое обновление включен для ваших пулов узлов.

  4. На панели навигации в разделе Пулы узлов щелкните пул по умолчанию .

  5. В разделе сведений о пуле узлов выполните следующие действия:

    1. Введите имя для пула узлов по умолчанию.
    2. Для узлов статической версии выберите версию узла .
    3. Введите Число узлов для создания в кластере. Вы должны иметь доступная квота ресурсов для узлов и их ресурсы (например, маршруты брандмауэра).
  6. На панели навигации в разделе Пулы узлов щелкните Узлы .

  7. В раскрывающемся списке Тип образа выберите нужный образ узла.

  8. Выберите значение по умолчанию Конфигурация машины использовать для экземпляров.Каждый тип машины оплачивается по-разному. То Тип машины по умолчанию: e2-medium . Цены на тип машины информацию см. в прайс-листе типа машины.

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

  10. Введите размер загрузочного диска .

  11. Необязательно: На панели навигации в разделе Пулы узлов щелкните Безопасность .

  12. Необязательно: В раскрывающемся списке Учетная запись службы выберите Управление идентификацией и доступом (IAM). служебная учетная запись, которую ваши приложения будут использовать при вызове Google Cloud API.Мы рекомендуем вам использовать учетную запись службы с минимальными привилегиями. вместо использования учетной записи службы по умолчанию, чтобы у ваших узлов не было дополнительных привилегий, которые им требуются.

  13. Нажмите Создать .

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

Шаблоны кластеров

Ранее GKE поддерживал шаблоны для кластеров. Эти шаблоны были удалены из Google Cloud Console, но по-прежнему доступны из следующих ссылки:

Что дальше

Попробуйте сами

Если вы новичок в Google Cloud, создайте учетную запись, чтобы оценить, как GKE работает в реальном мире сценарии.Новые клиенты также получают бесплатные кредиты в размере 300 долларов США для запуска, тестирования и развертывание рабочих нагрузок.

Попробуйте GKE бесплатно

Управление узлами в рое

Расчетное время чтения: 7 минут

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

Список узлов

Чтобы просмотреть список узлов в рое, запустите узел докера ls с узла менеджера:

.
  $ узел докера ls

ID ИМЯ ХОСТА СТАТУС ДОСТУПНОСТЬ МЕНЕДЖЕР СТАТУС
46aqrk4e473hjbt745z53cr3t узел-5 Готов Активен Доступен
61pi3d91s0w3b90ijw3deeb2q node-4 Готово Активно Достижимо
a5b2m3ogd48m8eu391pefq5u узел-3 Готов Активен
e7p8btxeu3ioshyuj6lxiv6g0 узел-2 Готов Активен
ehkv3bcimagdese79dn78otj5 * готовый активный лидер узла-1
  

Столбец ДОСТУПНОСТЬ показывает, может ли планировщик назначать задачи узел:

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

Столбец MANAGER STATUS показывает участие узла в консенсусе Raft:

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

Для получения дополнительной информации об администрировании Swarm см. руководство по администрированию Swarm.

Проверка отдельного узла

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

  $ docker node проверяет себя --pretty

ID: ehkv3bcimagdese79dn78otj5
Имя хоста: узел-1
Присоединился: 2016-06-16 22:52:44.92 +0000 всемирное время
Положение дел:
 Состояние: Готов
 Доступность: Активный
Статус менеджера:
 Адрес: 172.17.0.2:2377
 Статус плота: доступен
 Лидер: Да
Платформа:
 Операционная система: линукс
 Архитектура: x86_64
Ресурсы:
 Процессоры: 2
 Память: 1,954 ГиБ
Плагины:
  Сеть: оверлей, хост, мост, оверлей, ноль
  Объем: местный
Версия движка: 1.12.0-dev
  

Обновление узла

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

Изменить доступность узла

Изменение доступности узла позволяет:

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

Например, чтобы изменить узел менеджера на Слить доступность:

  $ обновление узла докера -- доступность стокового узла-1

узел-1
  

См. узлы списка для описания различной доступности опции.

Добавить или удалить метаданные метки

Метки узлов

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

Запустите docker node update --label-add на узле менеджера, чтобы добавить метаданные метки в узел. Флаг --label-add поддерживает либо <ключ> , либо <ключ>=<значение> . пара.

Передайте флаг --label-add один раз для каждой метки узла, которую вы хотите добавить:

  $ обновление узла докера --label-add foo --label-add bar=baz node-1

узел-1
  

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

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

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

Однако метки

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

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

Повышение или понижение уровня узла

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

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

Чтобы повысить уровень узла или набора узлов, запустите docker node повысить из диспетчера. узел:

  $ узел докера продвигает узел-3 узел-2

Узел node-3 повышен до менеджера в рое.Узел node-2 повышен до менеджера в рое.
  

Чтобы понизить уровень узла или набора узлов, запустите docker node понизить уровень с узла менеджера:

  $ docker node понизить уровень node-3 node-2

Менеджер узла-3 понижен в должности в рое.
Менеджер node-2 понижен в должности в рое.
  

docker node повысить и docker node понизить — это удобные команды для обновление докерного узла --role manager и обновление докерного узла --role worker соответственно.

Установить плагины на узлах роя

Если ваша служба роя зависит от одного или нескольких плагины, эти плагины должны быть доступны на каждый узел, где потенциально может быть развернут сервис. Вы можете вручную установите плагин на каждом узле или заскриптируйте установку. Вы также можете развернуть подключаемый модуль аналогично глобальной службе с использованием Docker API, указав PluginSpec вместо ContainerSpec .

Примечание

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

PluginSpec определяется разработчиком плагина. Чтобы добавить плагин на все узлы Docker, используйте сервис /создать API, передав PluginSpec JSON, определенный в TaskTemplate .

Покинуть рой

Запустите команду docker swarm leave на узле, чтобы удалить его из роя.

Например, чтобы оставить рой на рабочем узле:

  $ docker рой оставить

Нод покинул рой. 

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

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

Сведения о поддержании кворума и аварийном восстановлении см. Руководство по администрированию Swarm.

После того, как узел покинет рой, вы можете запустить команду docker node rm на узел менеджера, чтобы удалить узел из списка узлов.

Например:

Узнать больше

руководство, режим роя, узел

Кластеры Amazon Redshift — Amazon Redshift

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

Обзор кластеров Amazon Redshift

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

В настоящее время доступно ядро ​​Amazon Redshift версии 1.0. Однако, поскольку двигатель обновлено, для выбора могут быть доступны несколько версий ядра Amazon Redshift.

Кластеры и узлы в Amazon Redshift

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

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

При создании кластера в консоли Amazon Redshift (https://console.aws.amazon.com/redshift/) вы можете получить рекомендацию конфигурации вашего кластера на основе размера ваших данных и характеристики запроса.Чтобы использовать этот калькулятор размеров, найдите Помогите мне выбрать на консоли в регионах AWS, которые поддерживают типы узлов RA3. Дополнительные сведения см. в разделе Создание кластера.

При запуске кластера один параметр, который вы указываете, — это тип узла. Тип узла определяет ЦП, ОЗУ, емкость хранилища и тип накопителя для каждого узла.

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

узла RA3 с управляемым хранилищем позволяют оптимизировать хранилище данных за счет масштабирования и оплаты вычислений. и управлять хранилищем независимо. С RA3 вы выбираете количество узлов в зависимости от ваших требований к производительности и платите только за управляемое хранилище, которое вы используете. Размер вашего кластера RA3 зависит от объема данных, которые вы обрабатываете ежедневно. Вы запускаете кластеры, использующие типы узлов RA3, в виртуальном частном облако (VPC).Вы не можете запускать кластеры RA3 в EC2-Classic. Для получения дополнительной информации см. Создание кластера в VPC.

Управляемое хранилище Amazon Redshift

использует большие высокопроизводительные твердотельные накопители в каждом узле RA3 для быстрого локального хранения. и Amazon S3 для долгосрочного надежного хранения. Если объем данных в узле превышает размер больших локальных твердотельных накопителей, Управляемое хранилище Amazon Redshift автоматически переносит эти данные в Amazon S3.Вы платите один и тот же низкий тариф за управляемое хранилище Amazon Redshift независимо от того, где хранятся данные — на высокопроизводительных твердотельных накопителях или в Amazon S3. Для рабочих нагрузок, которым требуется постоянно растущее хранилище, управляемое хранилище позволяет автоматически масштабировать хранилище данных. емкость хранилища без добавления и оплаты дополнительных узлов.

узла DC2 позволяют создавать хранилища данных с интенсивными вычислениями с локальным хранилищем SSD. включены. Вы выбираете необходимое количество узлов в зависимости от размера данных и производительности. требования.Узлы DC2 хранят ваши данные локально для обеспечения высокой производительности. размер данных растет, вы можете добавить больше вычислительных узлов, чтобы увеличить емкость хранилища кластер. Для наборов данных менее 1 ТБ (сжатых) мы рекомендуем типы узлов DC2 для лучшая производительность по самой низкой цене. Если вы ожидаете, что ваши данные будут расти, мы рекомендуется использовать узлы RA3, чтобы вы могли независимо распределять вычислительные ресурсы и хранилище для достичь улучшенной цены и производительности.Вы запускаете кластеры, которые используют узел DC2 типы в виртуальном частном облаке (VPC). Вы не можете запускать кластеры DC2 в EC2-Классический. Дополнительные сведения см. в разделе Создание кластера в VPC.

узлов DS2 позволяют создавать большие хранилища данных с использованием жестких дисков (HDD), вместо этого мы рекомендуем использовать узлы RA3. Если вы используете узлы DS2, см. Обновление до типов узлов RA3 для обновления. методические рекомендации. Если вы используете восемь или более узлов ds2.xlarge или любое количество ds2.8xlarge, теперь вы можете перейти на RA3, чтобы получить в 2 раза больше места для хранения и улучшить производительность по той же цене.

Типы узлов доступны в различных размерах. Размер узла и количество узлов определяет общее хранилище для кластера. Дополнительные сведения см. в разделе Сведения о типе узла.

Некоторые типы узлов допускают использование одного узла (один узел) или двух или более узлов (многоузл).То минимальное количество узлов для кластеров некоторых типов узлов равно двум узлам. В кластере с одним узлом узел является общим для лидера и вычислительной функциональности. Кластеры с одним узлом не рекомендуются для выполнения рабочих нагрузок. В многоузловом кластере ведущий узел отделен от вычислительных узлов. Узел-лидер относится к тому же типу узла как вычислительные узлы. Вы платите только за вычислительные узлы.

Amazon Redshift применяет квоты к ресурсам для каждой учетной записи AWS в каждом регионе AWS.А квота ограничивает количество ресурсов, которые может использовать ваша учетная запись. создавать для данного типа ресурсов, например узлов или моментальных снимков, в регионе AWS. Для большего информацию о квотах по умолчанию, которые применяются к ресурсам Amazon Redshift, см. в разделе Ограничения Amazon Redshift в Общий справочник Amazon Web Services . Чтобы запросить увеличение, отправьте форму увеличения лимита Amazon Redshift.

Стоимость вашего кластера зависит от региона AWS, типа узла, количества узлов и зарезервированы ли узлы заранее.Для получения дополнительной информации о стоимости узлов, см. страницу с ценами на Amazon Redshift.

Сведения о типе узла

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

  • vCPU — количество виртуальных ЦП для каждого узел.

  • RAM — объем памяти в гибибайтах (ГиБ) для каждый узел.

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

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

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

  • Хранилище — емкость и тип хранилища для каждого узел.

  • Диапазон узлов — минимальное и максимальное количество узлов которые Amazon Redshift поддерживает для типа и размера узла.

    Вы можете быть ограничены меньшим количеством узлов в зависимости от установленной квоты. применяется к вашей учетной записи AWS в выбранном регионе AWS. Чтобы запросить увеличение, отправьте форму увеличения лимита Amazon Redshift.

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

Размер узла виртуальный ЦП ОЗУ (ГиБ) Слайсы по умолчанию на узел Квота управляемого хранилища на узел Диапазон узлов с созданием кластера Общая емкость управляемого хранилища
ра3.XLплюс 4 32 2 32 ТБ 1,5 1–16 2 1024 ТБ 2,4
ra3.4xlarge 12 96 4 128 ТБ 1 2–32 3 8192 ТБ 3,4
ра3.16xбольшой 48 384 16 128 ТБ 1 2–128 16 384 ТБ 4

1 Квота хранилища для управляемого хранилища Amazon Redshift.

2 Вы можете создать кластер с ra3.узел xlplus тип, который имеет до 16 узлов. Для одноузловых кластеров поддерживается только классическое изменение размера. Для кластеров с несколькими узлами вы можете изменить размер с помощью эластичного изменения размера максимум до 32 узлов.

3 Вы можете создать кластер с ra3.4xlarge или Тип узла ra3.16xlarge до 16 узлов. Вы можете изменить его размер с помощью эластичного изменить размер до максимум 64 узлов.

4 Общая квота управляемого хранилища — это максимальное количество узлов, умноженное на квоту управляемого хранилища на узел.

5 Общая квота управляемого хранилища для кластера ra3.xlplus с одним узлом составляет 4 ТБ.

Размер узла виртуальный ЦП ОЗУ (ГиБ) Слайсы по умолчанию на узел Хранилище на узел Диапазон узлов Общая вместимость
дс2.большой 4 31 2 Жесткий диск 2 ТБ 1–32 64 ТБ
ds2.8xlarge 36 244 16 Жесткий диск 16 ТБ 2–128 2 ПБ
Размер узла виртуальный ЦП ОЗУ (ГиБ) Слайсы по умолчанию на узел Хранилище на узел Диапазон узлов Общая вместимость
dc2.большой 2 15 2 160 ГБ NVMe-SSD 1–32 5,12 ТБ
dc2.8xlarge 32 244 16 2.56 ТБ NVMe-SSD 2–128 326 ТБ
dc1.большой 1 2 15 2 Твердотельный накопитель 160 ГБ 1–32 5,12 ТБ
дк1.8xбольшой 1 32 244 32 Твердотельный накопитель емкостью 2,56 ТБ 2–128 326 ТБ

1 Мы рекомендуем типы узлов DC2, а не типы узлов DC1. Для получения дополнительной информации об обновлении см. см. раздел Обновление типов узлов DC1 до DC2. типы узлов.

Предыдущие имена типов узлов

В предыдущих выпусках Amazon Redshift некоторые типы узлов имели разные имена. Ты могут использовать предыдущие имена в Amazon Redshift API и AWS CLI. Однако мы рекомендуем вам обновить все сценарии, которые ссылаются на эти имена, чтобы использовать вместо текущих имен. Текущее и предыдущее имена следующие.

Настоящее имя Предыдущие имена
дс2.большой ds1.xlarge, dw.hs1.xlarge, dw1.xlarge
ds2.8xlarge ds1.8xlarge, dw.hs1.8xlarge, dw1.8xlarge
dc1.большой dw2.большой
dc1.8xlarge dw2.8xlarge
Определение количества узлов

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

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

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

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

Информацию о ценах на узлы по запросу и зарезервированные узлы см. в разделе Цены на Amazon Redshift.

Используйте EC2-VPC при создании кластера

Кластеры Amazon Redshift

работают в инстансах Amazon EC2, настроенных для узла Amazon Redshift. тип и размер, которые вы выбираете.Создайте свой кластер с помощью EC2-VPC. Если вы все еще используете EC2-Classic, мы рекомендуем вам использовать EC2-VPC для повышения производительности и безопасности. Для дополнительную информацию об этих сетевых платформах см. в разделе «Поддерживаемые платформы» Руководство пользователя Amazon EC2 для инстансов Linux . Настройки вашей учетной записи AWS определяют, будет ли Вам доступны EC2-VPC или EC2-Classic.

Чтобы предотвратить проблемы с подключением между клиентскими инструментами SQL и базой данных Amazon Redshift, мы рекомендуем сделать одну из двух вещей.Вы можете настроить входящее правило, которое позволяет хосты для согласования размера пакета. Кроме того, вы можете отключить jumbo TCP/IP. кадры, установив максимальную единицу передачи (MTU) на 1500 в сети интерфейса (NIC) ваших инстансов Amazon EC2. Для получения дополнительной информации об этих подходы, см. Запросы зависают, а иногда и не выполняются добраться до кластера.

EC2-VPC

При использовании EC2-VPC ваш кластер работает в виртуальном частном облаке (VPC), которое логически изолирован от вашей учетной записи AWS.Если вы инициализируете свой кластер в EC2-VPC, вы контролируете доступ к своему кластеру, связывая один или несколько VPC группы безопасности с кластером. Дополнительные сведения см. в разделе Группы безопасности для вашего VPC. в Руководстве пользователя Amazon VPC .

Чтобы создать кластер в VPC, необходимо сначала создать подсеть кластера Amazon Redshift. группу, предоставив информацию о подсети вашего VPC, а затем укажите группу подсети при запуске кластера.Дополнительные сведения см. в разделе Группы подсетей кластера Amazon Redshift.

Дополнительные сведения об Amazon Virtual Private Cloud (Amazon VPC) см. на странице сведений о продукте Amazon VPC.

EC2-Классический

В EC2-Classic ваш кластер работает в одной плоской сети, которую вы поделиться с другими клиентами AWS. Если вы инициализируете свой кластер в EC2-Classic, вы контролируете доступ к своему кластеру, связывая один или несколько Amazon Redshift группы безопасности кластера с кластером.Дополнительные сведения см. в разделе Группы безопасности кластера Amazon Redshift.

Запустить кластер

Ваша учетная запись AWS может либо запускать экземпляры EC2-VPC и EC2-Classic, либо только EC2-VPC, в зависимости от региона. Чтобы определить, какая сетевая платформа у вас учетная запись поддерживает, а затем запустить кластер, сделать следующее:

  1. Решите, в каком регионе AWS вы хотите развернуть кластер.Для список регионов AWS, в которых доступен Amazon Redshift, см. Конечные точки Amazon Redshift в Общий справочник Amazon Web Services .

  2. Узнайте, какие платформы Amazon EC2 поддерживает ваша учетная запись в выбранном AWS Область, край. Вы можете найти эту информацию в консоли Amazon EC2. Для пошагового инструкции см. в разделе «Поддерживаемые платформы» в Руководство пользователя Amazon EC2 для инстансов Linux .

  3. Если ваша учетная запись поддерживает обе платформы, мы рекомендуем EC2-VPC. Если ваша учетная запись поддерживает только EC2-VPC, вы должны развернуть свой кластер в VPC.

  4. Запустите свой кластер Amazon Redshift. Вы можете создать кластер с помощью Консоль Amazon Redshift или с помощью Amazon Redshift API, AWS CLI или библиотек SDK.Дополнительные сведения об этих параметрах и ссылки на соответствующие документацию см. в разделе Что такое Amazon Redshift?.

Обзор типов узлов RA3

Мы рекомендуем обновить существующие рабочие нагрузки, работающие в кластерах типа узла DS2, до Типы узлов RA3 для повышения производительности и увеличения объема хранилища. емкость.Узлы RA3 обеспечивают следующие преимущества:

  • Гибкие возможности увеличения вычислительной мощности без увеличения затрат на хранение. И они масштабируйте хранилище без избыточного выделения вычислительных мощностей.

  • Они используют высокопроизводительные твердотельные накопители для ваших горячих данных и Amazon S3 для холодных данных. Таким образом, они обеспечивают легкость использование, экономичное хранилище и высокая производительность запросов.

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

Рассмотрите возможность выбора типов узлов RA3 в следующих случаях:

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

  • Вы запрашиваете часть ваших общих данных.

  • Объем ваших данных быстро растет или ожидается быстрый рост.

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

Чтобы использовать типы узлов RA3, ваш регион AWS должен поддерживать RA3. Для большего информацию см. в разделе Доступность типа узла RA3 в регионах AWS.

Вы можете использовать ra3.xlplus типы узлов только с версией кластера 1.0.21262 или более поздней. Ты может просмотреть версию существующего кластера с помощью консоли Amazon Redshift. Для большего информацию см. в разделе Определение обслуживания кластера версия.

Убедитесь, что вы используете новую консоль Amazon Redshift при работе с типами узлов RA3. Исходная консоль не поддерживает все операции RA3.

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

При использовании одноузловых типов узлов RA3 учитывайте следующее.

  • AQUA поддерживается.

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

  • Для изменения типов узлов поддерживается только классическое изменение размера.Изменение типа узла с эластичным изменением размера или восстановлением моментального снимка не поддерживается. Поддерживаются следующие сценарии:

    • Классическое изменение размера ds2.xlarge с 1 узлом на ra3.xlplus с 1 узлом и наоборот.

    • Классическое изменение размера ds2.xlarge с 1 узлом на ra3.xlplus с несколькими узлами и наоборот.

    • Классическое изменение размера многоузлового ds2.xlarge на ra3.xlplus с 1 узлом и наоборот.

    • Классическое изменение размера dc2.xlarge с 1 узлом на ra3.xlplus с 1 узлом и наоборот.

    • Классическое изменение размера одноузлового dc2.xlarge на многоузловой ra3.xlplus и наоборот.

    • Классическое изменение размера многоузлового dc2.xlarge до одноузлового ra3.xlplus и наоборот.

Работа с управляемым хранилищем Amazon Redshift

Благодаря управляемому хранилищу Amazon Redshift вы можете хранить и обрабатывать все свои данные в Amazon Redshift, получить больше гибкости для раздельного масштабирования вычислительной мощности и емкости хранения.Ты продолжайте принимать данные с помощью команды COPY или INSERT. Для оптимизации производительности и управления автоматическим размещением данных между уровнями хранилище, Amazon Redshift использует преимущества таких оптимизаций, как температура блока данных, возраст блока данных и модели рабочей нагрузки. При необходимости Amazon Redshift масштабирует хранилище автоматически в Amazon S3 без каких-либо ручных действий.

Информацию о стоимости хранения см. в разделе цен на Amazon Redshift.

Управление типами узлов RA3

Чтобы воспользоваться преимуществом отделения вычислений от хранилища, вы можете создать или обновить свой кластер. с типом узла RA3. Чтобы использовать типы узлов RA3, создайте свои кластеры в виртуальное частное облако (EC2-VPC).

Чтобы изменить количество узлов кластера Amazon Redshift с типом узла RA3, выполните одно из следующих действий:

  • Добавление или удаление узлов с помощью эластичной операции изменения размера. В некоторых ситуациях удаление узлов из кластера RA3 не допускается с эластичным изменением размера. Для например, когда при обновлении количества узлов 2:1 число сегментов на узел становится равным 32.Дополнительные сведения см. в разделе Изменение размера кластеров. Если эластичное изменение размера недоступно, используйте классическое изменение размера.

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

Доступность типа узла RA3 в регионах AWS

Типы узлов RA3 доступны только в следующих регионах AWS:

  • Восток США (Сев.Вирджиния) Регион (us-east-1)

  • Регион Восток США (Огайо) (us-east-2)

  • Западный регион США (Северная Калифорния) (us-west-1)

  • Западный регион США (Орегон) (us-west-2)

  • Азиатско-Тихоокеанский регион (Гонконг) (ap-east-1)

  • Азиатско-Тихоокеанский регион (Джакарта) (ap-southeast-3) — только ra3.Поддерживаются типы узлов 4xlarge и ra3.16xlarge

  • Азиатско-Тихоокеанский регион (Мумбаи) (ap-south-1)

  • Азиатско-Тихоокеанский регион (Сеул) (ap-northeast-2)

  • Азиатско-Тихоокеанский регион (Сингапур) (ap-southeast-1)

  • Азиатско-Тихоокеанский регион (Сидней) (ap-southeast-2)

  • Азиатско-Тихоокеанский регион (Токио) (ap-northeast-1)

  • Канада (Центральный) Регион (ca-central-1)

  • Европа (Франкфурт) Регион (eu-central-1)

  • Китай (Пекин) Регион (cn-north-1)

  • Регион Китая (Нинся) (cn-northwest-1)

  • Европа (Ирландия) Регион (eu-west-1)

  • Регион Европы (Лондон) (eu-west-2)

  • Европа (Париж) Регион (eu-west-3)

  • Европа (Стокгольм) Регион (eu-north-1)

  • Регион Южной Америки (Сан-Паулу) (sa-east-1)

  • AWS GovCloud (Восток США) (us-gov-east-1)

  • AWS GovCloud (Запад США) (us-gov-west-1)

Обновление до типов узлов RA3

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

  • Восстановление из моментального снимка – Amazon Redshift использует самый последний моментальный снимок вашего кластера DS2 или DC2 и восстанавливает его для создания нового кластера RA3.Как только создание кластера будет завершено (обычно в течение нескольких минут), Узлы RA3 готовы к полной рабочей нагрузке. Поскольку вычисления отделены от хранилища, горячие данные поступают в локальный кеш с высокой скоростью. благодаря большой пропускной способности сети. Если вы восстанавливаетесь из последнего моментального снимка DS2 или DC2, RA3 сохраняет информацию о горячих блоках рабочей нагрузки DS2 или DC2 и заполняет свой локальный кэш самыми горячими блоками.Для получения дополнительной информации см. Восстановление кластера со снимка.

    Чтобы сохранить одну и ту же конечную точку для ваших приложений и пользователей, вы можете переименовать новую Кластер RA3 с тем же именем, что и исходный кластер DS2 или DC2. Чтобы переименовать кластер, измените кластер в консоли Amazon Redshift или ModifyCluster Работа с API.Дополнительные сведения см. в разделе Переименование кластеров или операция API ModifyCluster в Справочник API Amazon Redshift .

  • Elastic resize — изменение размера кластера с помощью эластичного изменения размера. Когда вы используете эластичное изменение размера для изменения типа узла, Amazon Redshift автоматически создает моментальный снимок, создает новый кластер, удаляет старый кластер и переименовывает новый кластер. Операция эластичного изменения размера может выполняться по требованию или может быть запланирована на будущее.Вы можете быстро обновить существующие кластеры узлов DS2 или DC2 до уровня RA3 с эластичным изменением размера. Для получения дополнительной информации см. Эластичный размер.

В следующей таблице приведены рекомендации по обновлению до типов узлов RA3. (Эти рекомендации также относятся к зарезервированным узлам.)

Существующий тип узла Существующее количество узлов Рекомендуемый новый тип узла Действие обновления

ds2.xlarge

1

ra3.xlplus

Создайте 1-узел ra3.кластер xlplus 1 .

ds2.xlarge

2

ra3.xlplus

Создайте кластер ra3.xlplus с двумя узлами 1 .

ds2.xlarge

3

ра3.XLплюс

Создайте кластер ra3.xlplus с двумя узлами 1 .

ds2.xlarge

4

ra3.xlplus

Создайте кластер ra3.xlplus с 3 узлами 1 .

ds2.xlarge

5

ра3.XLплюс

Создайте кластер ra3.xlplus с 4 узлами 1 .

ds2.xlarge

6

ra3.xlplus

Создайте кластер ra3.xlplus с 4 узлами 1 .

ds2.xlarge

7

ра3.XLплюс

Создайте кластер ra3.xlplus из 5 узлов 1 .

ds2.xlarge

8

ra3.4xlarge

Создайте двухузловой кластер ra3.4xlarge 1 .

дс2.большой

9

ra3.4xlarge

Создайте кластер ra3.4xlarge из 3 узлов 1 .

ds2.xlarge

10

ra3.4xlarge

Создайте 3-узловой ra3.4xбольшой кластер 1 .

ds2.xlarge

11-128

ra3.4xlarge

Создайте 1 узел ra3.4xlarge на каждые 4 узла ds2.xlarge 1 .

ds2.8xlarge

2–15

ра3.4xбольшой

Создайте 2 узла ra3.4xlarge на каждый 1 узел ds2.8xlarge 1 .

ds2.8xlarge

16–128

ra3.16xlarge

Создайте 1 узел ra3.16xlarge на каждые 2 узла ds2.8xlarge 1 .

dc2.8xlarge

2–15

ra3.4xlarge

Создайте 2 узла ra3.4xlarge на каждый 1 узел dc2.8xlarge 1 .

dc2.8xlarge

16–128

ra3.16xlarge

Создайте 1 узел ra3.16xlarge на каждые 2 узла dc2.8xlarge 1 .

dc2.large

1–4

нет

Сохранить существующий кластер dc2.large.

dc2.large

4–15

ра3.XLплюс

Создайте 3 узла ra3.xlplus на каждые 8 ​​узлов dc2.large 1 .

dc2.large

16–32

ra3.4xlarge

Создайте 1 узел ra3.4xlarge на каждые 8 ​​узлов dc2.large 1, 2 .

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

2 Кластеры с типом узла dc2.large ограничены 32 узлами.

Минимальное количество узлов для некоторых типов узлов RA3 — 2 узла. Учитывайте это при создании кластера RA3.

Обновление зарезервированных узлов DS2 до зарезервированных узлов RA3 во время эластичного изменения размера или восстановления моментального снимка

Если у вас есть зарезервированные узлы DS2, вы можете обновить их с помощью зарезервированного узла RA3. обновления с помощью консоли Amazon Redshift или интерфейса командной строки AWS.На консоли есть несколько способов сделать это.

Один из способов — обновить зарезервированные узлы DS2 до RA3 во время эластичного изменения размера. Если вы зарезервировали узлы и выбрали узлы RA3, консоль проведет вас через процесс обновления зарезервированного узла. С технической точки зрения эластичное изменение размера работает лучше всего. одинаково как для зарезервированных, так и для незарезервированных узлов.

Если вы измените размер кластера с рекомендуемого размера, при настройке эластичное изменение размера, обновление зарезервированного узла RA3 недоступно и не отображается на консоль. (Вы по-прежнему можете обновить зарезервированные узлы DS2 до RA3, но изменение размера не включает обновление зарезервированного узла RA3 как часть процесса.) Также обратите внимание, что размер кластера, который вы хотите может быть недоступен из-за ограничений размера кластера для эластичного изменения размера.Для Например, если у вас есть кластер зарезервированных узлов DS2 с 4 узлами, вы не сможете выберите кластер RA3 с тремя узлами. В этом случае вы можете выполнить классическое изменение размера, чтобы получить желаемый размер кластера.

После изменения размера кластера выполняется несколько шагов. Во-первых, данные переносятся к кластеру RA3. Затем аренда зарезервированного узла DS2 преобразуется в RA3. аренда зарезервированного узла.Обратите внимание, что время переноса данных может варьироваться в зависимости от размер кластера и тип изменения размера: эластичный или классический. На случай, если при классическом изменении размера перенос данных обычно занимает несколько часов.

После запуска изменения размера отслеживайте ход выполнения, просматривая сообщения в События , доступны на Amazon Redshift приборная панель .Существует уведомление о событии для изменения размера, а другое для обновления зарезервированного узла. Сведения о работе с событиями см. в разделе События Amazon Redshift. После resize, активный кластер с измененным размером появится в Консоли управления AWS. Вы также можете просмотреть преобразованная аренда зарезервированного узла RA3. Исходный зарезервированный(е) узел(ы) DS2 может по-прежнему появляются на консоли примерно сутки. Вы не платите за них. Не удалять исходный зарезервированный узел DS2, пока вы не убедитесь, что кластер RA3 активен и генерируется преобразованная аренда зарезервированного узла.

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

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

Если у вас есть дополнительные вопросы об обновлении зарезервированных узлов до RA3, для Если вы хотите обновить зарезервированные узлы DC2 до RA3, обратитесь в службу поддержки AWS.Для информацию о ценах на узлы по запросу и зарезервированные узлы см. в разделе Цены на Amazon Redshift.

Если вы уже приобрели зарезервированные узлы DS2, обратитесь в AWS за помощью. преобразование зарезервированных узлов DS2 в зарезервированные узлы RA3. Чтобы связаться с AWS для получения дополнительной информации информация см. Инстансы Amazon Redshift RA3 с управляемым хранилищем.

Обновление типов узлов DC1 до DC2 типы узлов

Чтобы воспользоваться преимуществами повышения производительности, вы можете обновить кластеры DC1 до Типы узлов DC2.

Кластеры, использующие тип узла DC2, должны запускаться в виртуальном частном облаке. (EC2-ВПК).

Если ваш кластер DC1 не находится в VPC:

Если ваш кластер DC1 уже находится в VPC, выберите один из следующих методов:

  • Измените размер кластера DC1 и измените тип узла на DC2 как часть операции. Ваш кластер недоступен в течение определенного периода времени во время операции изменения размера.Для получения дополнительной информации см. Изменение размера кластеров в Amazon Redshift.

  • Создайте моментальный снимок кластера DC1, затем восстановите моментальный снимок в кластере DC2 в VPC. Для получения дополнительной информации см. Восстановление кластера со снимка.

При обновлении с типов узлов DC1 до DC2 учитывайте следующее.

  • Кластеры DC1, заполненные на 100 %, могут не обновиться до эквивалентного количества узлов DC2.Если нужно больше места на диске, можно:

  • Кластеры DC2 не поддерживают сеть EC2-Classic. Если ваш кластер DC1 не работает в VPC, создайте его для миграции DC2. Дополнительные сведения см. в разделе Управление кластерами в VPC.

  • При изменении размера кластера он может быть переведен в режим только для чтения на время операции. Дополнительные сведения см. в разделе Изменение размера кластеров в Amazon Redshift.

  • Если вы приобрели зарезервированные узлы DC1, вы можете обновить зарезервированные узлы DC1 до узлов DC2 до конца срока. Дополнительные сведения о том, как изменить резервирование с помощью интерфейса командной строки AWS, см. Обновление зарезервированных узлов с помощью интерфейса командной строки AWS.

  • Если вы используете восстановление для обновления с dc1.large до dc2.large и изменяете количество узлов, то моментальный снимок должен быть создан в версии кластера 1.0.10013 или выше.

  • Если вы используете восстановление для обновления с dc1.8xlarge до dc2.8xlarge, моментальный снимок должен быть создан в версии кластера 1.0.10013 или более поздней.

  • Если вы используете эластичное изменение размера для обновления с DC1 до DC2 и изменяете количество узлов, то кластер должен иметь версию кластера 1.0.10013 или более позднюю.

  • Если моментальный снимок кластера dc1.8xlarge для обновления сделан из кластера более ранней версии, чем 1.0.10013, то сначала восстановить моментальный снимок из dc1.8xlarge в новый кластер dc1.8xlarge с таким же количеством узлов. Затем используйте один из следующих методов для обновления нового dc1.8xlarge:

Обновление DS2 кластер от EC2-Classic до EC2-VPC

Кластеры Amazon Redshift

работают в инстансах Amazon EC2, настроенных для узла Amazon Redshift. тип и размер, который вы выбираете.Мы рекомендуем вам обновить свой кластер до EC2-Classic. для запуска в VPC с использованием EC2-VPC для повышения производительности и безопасности.

Вопросы региона и зоны доступности

Amazon Redshift доступен в нескольких регионах AWS. По умолчанию Amazon Redshift выделяет кластер в случайно выбранной зоне доступности (AZ) в регионе AWS, который вы выберите. Все узлы кластера предоставляются в одной и той же зоне доступности.

При необходимости вы можете запросить определенную зону доступности, если в этой зоне доступен Amazon Redshift. Для например, если у вас уже есть инстанс Amazon EC2, работающий в одной зоне доступности, вы можете создайте свой кластер Amazon Redshift в той же зоне, чтобы уменьшить задержку. С другой стороны, вы возможно, вы захотите выбрать другую зону доступности для более высокой доступности. Amazon Redshift может быть недоступен во всех зонах доступности в регионе AWS.

Список поддерживаемых регионов AWS, в которых можно выделить кластер Amazon Redshift, см. Конечные точки Amazon Redshift в Общий справочник Amazon Web Services .

Обслуживание кластера

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

Окна обслуживания

Amazon Redshift случайным образом назначает 30-минутное окно обслуживания из 8-часового блока время на регион AWS, происходящее в случайный день недели (с понедельника по воскресенье, включительно).

Обслуживание по умолчанию окна

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

  • Восток США (Сев.Вирджиния) Регион: 03:00–11:00 UTC

  • Регион Восток США (Огайо): 03:00–11:00 UTC

  • Запад США (Северная Калифорния) Регион: 06:00–14:00 UTC

  • Западный регион США (Орегон): 06:00–14:00 UTC

  • Африка (Кейптаун) Регион: 20:00–04:00 UTC

  • Азиатско-Тихоокеанский регион (Гонконг): 13:00–21:00 UTC

  • Азиатско-Тихоокеанский регион (Джакарта): 15:00–23:00 UTC

  • Азиатско-Тихоокеанский регион (Мумбаи): 16:30–00:30 UTC

  • Азиатско-Тихоокеанский регион (Осака): 13:00–21:00 UTC

  • Азиатско-Тихоокеанский регион (Сеул): 13:00–21:00 UTC

  • Азиатско-Тихоокеанский регион (Сингапур): 14:00–22:00 UTC

  • Азиатско-Тихоокеанский регион (Сидней): 12:00–20:00 UTC

  • Азиатско-Тихоокеанский регион (Токио): 13:00–21:00 UTC

  • Канада (Центральный регион): 03:00–11:00 UTC

  • Китай (Пекин) Регион: 13:00–21:00 UTC

  • Китай (Нинся), регион: 13:00–21:00 UTC

  • Европа (Франкфурт) Регион: 06:00–14:00 UTC

  • Европа (Ирландия) Регион: 22:00–06:00 UTC

  • Европа (Лондон) Регион: 22:00–06:00 UTC

  • Европа (Милан) Регион: 21:00–05:00 UTC

  • Европа (Париж) Регион: 23:00–07:00 UTC

  • Европа (Стокгольм) Регион: 23:00–07:00 UTC

  • Регион Ближнего Востока (Бахрейн): 13:00–21:00 UTC

  • Южная Америка (Сан-Паулу) Регион: 19:00–03:00 UTC

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

Вы можете изменить окно запланированного обслуживания, изменив кластер, либо программно, либо с помощью консоли Amazon Redshift. Окно должно быть на не менее 30 минут и не более 24 часов. Дополнительные сведения см. в разделе Управление кластерами с помощью консоли.

Отсрочка технического обслуживания

Если вам нужно изменить график обслуживания вашего кластера, у вас есть возможность отложить техническое обслуживание на срок до 45 дней.Например, если обслуживание вашего кластера окно настроено на среду с 8:30 до 9:00 UTC, и вам необходимо иметь доступ к кластер в это время, вы можете отложить обслуживание на более поздний период времени. Мы будем не выполнять какое-либо обслуживание вашего кластера, когда вы указали отсрочку, если нам не нужно обновлять оборудование.

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

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

Вы не можете отложить техническое обслуживание после его начала.

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

Выбор обслуживания кластера треки

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

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

  • Текущий — Использовать самый последний утвержденная версия кластера.

  • Завершающий — использовать кластерную версию до текущей версии.

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

Например, предположим, что ваш кластер в настоящее время работает под управлением версии 1.0.2762 и текущая версия Amazon Redshift — 1.0,3072. Если вы установите значение отслеживания обслуживания на Текущий , ваш кластер обновлен до версии 1.0.3072 (версия следующий утвержденный выпуск) в течение следующего периода обслуживания. Если вы установите значение отслеживания обслуживания до Trailing , ваш кластер не обновляется до тех пор, пока не появится новая версия после 1.0.3072.

Треки предварительного просмотра

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

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

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

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

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

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

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

Переключение между путями обслуживания

Изменение дорожек для кластера обычно является разовым решением. Вам следует проявляйте осторожность при смене трассы. Если вы измените дорожку обслуживания с Завершающий до Текущий , мы будем обновлять кластер к версии Current Track Release во время следующее окно обслуживания.Однако если вы измените дорожку обслуживания кластера на После мы не будем обновлять ваш кластер, пока не будет новый выпуск после версии Current .

Техническое обслуживание и восстановление

Моментальный снимок наследует отслеживание обслуживания исходного кластера. Если вы измените отслеживание обслуживания исходного кластера после создания моментального снимка, моментального снимка и исходный кластер находится на разных дорожках.При восстановлении из снимка новый кластер будет находиться на пути обслуживания, унаследованном от исходного кластера. Вы можете изменить дорожку обслуживания после завершения операции восстановления. Изменение размера кластер не влияет на отслеживание обслуживания кластера.

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

Управление версиями кластера

Отслеживание обслуживания — это серия релизов.Вы можете решить, включен ли ваш кластер Current track или Trailing track. Если вы поместите свой кластер на дорожку Current , он всегда будет обновлен до самого последнего кластера. релизную версию во время периода ее обслуживания. Если вы поместите свой кластер на Замыкающая дорожка , она всегда будет запускать кластер версия выпуска, которая была выпущена непосредственно перед самой последней выпущенной версия.

Столбец Статус выпуска в списке консоли Amazon Redshift clusters указывает, доступен ли один из ваших кластеров для обновления.

Откат версии кластера

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

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

Доступна новая консоль для Amazon Redshift. Выберите либо Новая консоль или инструкции Исходная консоль в зависимости от используемой консоли. Новая консоль инструкции открыты по умолчанию.

Чтобы вернуться к предыдущей версии кластера

  1. Войдите в Консоль управления AWS и откройте консоль Amazon Redshift по адресу https://консоль.aws.amazon.com/redshift/.

  2. В меню навигации выберите КЛАСТЕРЫ .

  3. Выберите кластер для отката.

  4. Для Действия выберите Откат версия кластера . Кластер отката появится страница версии .

  5. Если доступна версия для отката, следуйте инструкциям на странице.

  6. Выбрать Откатиться сейчас .

Чтобы вернуться к предыдущей версии кластера

  1. Войдите в Консоль управления AWS и откройте консоль Amazon Redshift по адресу https://консоль.aws.amazon.com/redshift/.

  2. На панели навигации выберите Кластеры .

  3. Выберите кластер, который вы хотите откатить, и выберите Статус вкладка.

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

  4. Выберите Откат к выпуску (номер выпуска) .

Определение обслуживания кластера версия

Вы можете определить версию ядра и базы данных Amazon Redshift с помощью консоли Amazon Redshift.

Доступна новая консоль для Amazon Redshift. Выберите либо Новая консоль или инструкции Исходная консоль в зависимости от используемой консоли. Новая консоль инструкции открыты по умолчанию.

Чтобы найти версию кластера

  1. Войдите в Консоль управления AWS и откройте консоль Amazon Redshift по адресу https://console.aws.amazon.com/redshift/.

  2. В меню навигации выберите КЛАСТЕРЫ , затем выберите имя кластера из списка, чтобы открыть сведения о нем.Отображаются сведения о кластере, которые могут включать Производительность кластера , Мониторинг запросов , Базы данных , Общие данные , Расписания , Техническое обслуживание и Свойства вкладки.

  3. Выберите вкладку Обслуживание для получения дополнительных сведений.

  4. В разделе Техническое обслуживание найдите Текущая версия кластера .

Хотя консоль отображает эту информацию в одном поле, это два параметры в Amazon Redshift API, ClusterVersion и Номер Ревизии Кластера . Дополнительные сведения см. в разделе Кластер в Справочник API Amazon Redshift .

Вы можете определить версии ядра и базы данных Amazon Redshift для вашего кластер в Версия кластера на консоли.Первый два раздела номера — это версия кластера, а последний раздел — конкретный номер версии базы данных в кластере. в В следующем примере версия кластера — 1.0, а версия базы данных номер 884.

Хотя консоль отображает эту информацию в одном поле, это два параметра в Amazon Redshift API, ClusterVersion и Номер Ревизии Кластера .Дополнительные сведения см. в разделе Кластер в Справочник API Amazon Redshift .

Чтобы указать, следует ли автоматически обновлять подсистему Amazon Redshift в вашем кластере, если становится доступной новая версия движка, используйте настройку Разрешить обновление версии . Этот параметр не влияет на версию базы данных обновления, которые применяются во время периода обслуживания, указанного для ваш кластер.Обновления ядра Amazon Redshift — основная версия обновления , а обновления базы данных Amazon Redshift являются второстепенными обновление версии . Вы можете отключить автоматическое обновление версий для только основные версии. Для получения дополнительной информации о периодах обслуживания для несовершеннолетних обновления версии, см. Периоды обслуживания.

Аварийный сигнал свободного места на диске по умолчанию

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

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

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

При срабатывании сигнала тревоги CloudWatch служба Amazon Simple Notification Service (Amazon SNS) отправляет уведомление указанному получателей, чтобы предупредить их о достижении процентного порога.Amazon SNS использует тему для указать получателей и сообщение, отправляемое в уведомлении. Вы можете использовать существующая тема Amazon SNS; в противном случае тема создается на основе настроек, которые вы указать при запуске кластера. Вы можете отредактировать тему для этого будильника после того, как запустить кластер. Дополнительные сведения о создании тем Amazon SNS см. в разделе Начало работы с Amazon Simple Notification Service.

После запуска кластера вы можете просмотреть и отредактировать аварийный сигнал из панели управления кластера. Окно состояния под CloudWatch Alarms .То имя процент-используемое-дисковое-пространство-по-умолчанию-< строка > . Вы можете открыть будильник, чтобы просмотреть тему Amazon SNS, с которой он связан, и отредактировать будильник. настройки. Если вы не выбрали для использования существующую тему Amazon SNS, используйте тему, созданную для вас. имеет имя < имя_кластера >-default-alarms (< получатель >) ; Например, examplecluster-default-alarms ([email protected]ком) .

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

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

Состояние кластера

Состояние кластера отображает текущее состояние кластера.Следующая таблица предоставляет описание для каждого состояния кластера.

Статус Описание
в наличии Кластер запущен и доступен.
в наличии, подготовка к изменению размера Кластер готовится к эластичному изменению размера.Кластер работает и доступен для запросов на чтение и запись, но кластер операции, такие как создание моментального снимка, недоступны.
доступно, изменение размера-очистка Операция эластичного изменения размера завершает передачу данных в новый узлы кластера. Кластер запущен и доступен для чтения и записи запросы, но кластерные операции, такие как создание моментального снимка, не доступный.
отмена-изменение размера Операция изменения размера отменяется.
создание Amazon Redshift создает кластер. Дополнительные сведения см. в разделе Создание кластера.
удаление Amazon Redshift удаляет кластер.Дополнительные сведения см. в разделе Удаление кластера.
финальный снимок Amazon Redshift делает последний снимок кластера перед его удалением. Дополнительные сведения см. в разделе Удаление кластера.
аппаратный сбой

В кластере произошел аппаратный сбой.

Если у вас есть кластер с одним узлом, узел нельзя заменить. К восстановите свой кластер, восстановите снимок. Для получения дополнительной информации см. Снимки Amazon Redshift.

несовместимость-hsm Amazon Redshift не может подключиться к аппаратному модулю безопасности (HSM). Проверить Конфигурация HSM между кластером и HSM.Для получения дополнительной информации см. Шифрование для Amazon Redshift с использованием аппаратной защиты модули.
несовместимая сеть Проблема с базовой конфигурацией сети. Сделать убедитесь, что VPC, в котором вы запустили кластер, существует и его настройки правильные. Дополнительные сведения см. в разделе Управление кластерами в VPC.
несовместимые параметры Проблема с одним или несколькими значениями параметров в связанном группа параметров, и значение или значения параметра не могут быть применены. Измените группу параметров и обновите все недопустимые значения. Для большего информацию см. в разделе Группы параметров Amazon Redshift.
восстановление несовместимости Возникла проблема при восстановлении кластера из моментального снимка.Пытаться повторное восстановление кластера с использованием другого моментального снимка. Для большего информацию см. в моментальных снимках Amazon Redshift.
модификация Amazon Redshift применяет изменения к кластеру. Для получения дополнительной информации см. Изменение кластера.
приостановлено Кластер приостановлен.Для получения дополнительной информации см. Приостановка и возобновление кластеров.
перезагрузка Amazon Redshift перезагружает кластер. Дополнительные сведения см. в разделе Перезагрузка кластера.
переименование Amazon Redshift применяет к кластеру новое имя. Чтобы получить больше информации, см. Переименование кластеров.
изменение размера Amazon Redshift изменяет размер кластера. Дополнительные сведения см. в разделе Изменение размера кластера.
поворотные ключи Amazon Redshift выполняет ротацию ключей шифрования для кластера. Для большего информацию см. в разделе Смена ключей шифрования в Amazon Redshift.
хранение-полный Кластер достиг своей емкости хранилища.Измените размер кластера на добавить узлы или выбрать другой размер узла. Для получения дополнительной информации см. Изменение размера кластера.
обновление-hsm Amazon Redshift обновляет конфигурацию HSM. .

Node Engines: помощь разработчикам во всем мире во избежание фантомных ошибок | Пейдж Нидрингхаус

Позвольте мне подготовить для вас сцену: вы пишете код, занимаетесь своими делами, запускаете новую блестящую функцию для своего приложения, когда внезапно начинает мигать красный свет (или загорается канал #support в Slack). вверх, любой из них) и все руки на палубе; есть проблема в производстве.🚨

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

Каждый разработчик слышал (и говорил) это не менее одиннадцати миллиардов раз.

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

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

Вы никогда не задумываетесь о том, какую версию Node или NPM использует ваша машина локально, а какую версию Node.js использует ваша производственная среда… пока это не имеет значения.

Реальные примеры того, почему это важно

Я говорю из личного опыта, когда говорю, что приложение AngularJS 1.5, которое поддерживает моя команда, работает ТОЛЬКО в Node версии 9, однако, когда мы развернули нашу производственную облачную среду, пакет сборки Node, который был развернут, с ним, втянул в v6.Версия 6?!? Кто вообще разрабатывает такую ​​старую версию Node??

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

Точно так же нашему приложению React требуется Node версии 10 или выше, чтобы использовать все преимущества узлов ES6 и выше, которые у него есть. Это должно быть , по крайней мере, v10 или выше, никаких если, и или но.

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

Но как нам убедиться, что мы получим нужный пакет сборки? Как мы гарантируем, что при развертывании из нашей локальной среды разработки в нашу облачную производственную среду, Node.js время выполнения такое же? Что он может поддерживать зависимости Node, необходимые нашему проекту?

На самом деле это проще, чем вы думаете. Читайте мое решение.

Легко: Двигатели

Я не виню вас, если это ваш первоначальный ответ, он был и моим.

Двигатели? Что это хотя бы значит??

Что такое узлы узлов?

Node Engines — это немного обсуждаемая (но, на мой взгляд, довольно важная) конфигурация, которую можно указать в файле package.json , который сообщает любому (или любой машине), на котором запущено приложение JavaScript, какая версия Node требуется для кода. работать.

Собственные документы NPM говорят при определении движков:

«Вы можете указать версию узла, на которой работает ваш материал» — NPM

Довольно очевидно.

На практике это означает следующее: если включены движков , при развертывании сборки JavaScript (в зависимости от того, как указано поле движка) она будет искать версию Node не ниже версии, настроенной в пакете . json , затем загрузите его и установите все зависимости node_module , используя этот движок.

Если движок не указан, проект находится во власти богов сборочных пакетов и предполагает, что подойдет любая старая версия Node, и загрузит зависимости с какой-то случайной версией Node и NPM. Вот как мы заканчиваем пожарные учения, подобные описанному выше сценарию.

На самом деле вы можете указать версию Node.js, версию NPM и версию Yarn, которую проект использует в своих движках , что довольно приятно.

Просто для ясности: поле Engines будет проверено при установке пакета, а не при запуске приложения.

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

Шаг 1. Определите свою локальную среду выполнения разработки

Первый шаг — выяснить, какую версию Node вы разрабатываете локально. Достаточно просто.

Просто откройте окно терминала и введите:

 node -v 

Затем вы должны увидеть версию Node, с которой вы работаете, распечатанную на терминале.Смотрите скриншот ниже:

Как увидеть локальную версию Node, работающую на вашем компьютере. Для меня это в настоящее время v11.10.0

. Если вам когда-нибудь понадобится переключить версии Node для локальной разработки, я настоятельно рекомендую NVM (Node Version Manager), о котором я также написал здесь в блоге.

Но это по касательной. Все, что вам нужно на данный момент, это знать, в какой версии Node вы сейчас работаете. Перейдем к шагу 2.

Шаг 2: Укажите ваш Node Engine в пакете

.json

Теперь, когда вы знаете версию Node, вы можете указать ее в файле package.json вашего проекта. Ниже пара примеров, как выглядит конфиг двигателей .

Этот пример включает как версию Node, которая больше или равна v11.10.2 и меньше v12.0.0, так и версию NPM, равную точно 5.8.0.

 ... // код выше, например зависимости и другие спецификации 
"engines": {
"node": ">=11.10.2 <12.0.0",
"npm": "5.8.0"
},
... // больше кода ниже здесь

Или этот пример, который включает версию Node около 10.15.0.

 ... // больше кода 
"engines": {
"node" : "~10.15.0"
},
... // больше кода

Указание версий Node, NPM и Yarn аналогично указанию их для зависимостей в вашем package.json , вы можете быть настолько конкретными, насколько вы хотите до точной версии, укажите нижний предел, укажите диапазон или приблизительное значение.Тебе решать.

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

Шаг 3. Запустите сценарии сборки развертывания и проверьте совпадения пакетов сборки

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

Ниже приведены некоторые журналы с нашего сервера Jenkins, на котором выполняются все наши сборки для нашего приложения AngularJS, для которого требуется версия Node 9. Как видно на первом снимке экрана, сборка проверяет наличие конкретной версии Node на сервере. и находит 9.11.2, указанную в package.json , поэтому устанавливает эту версию на сервер сборки, если она еще не доступна.

Вот подтверждение того, что версия Node.js работает на сервере сборки Jenkins.

А вот еще один пример снимка экрана, на этот раз нашего приложения React, которому требуется версия Node 10 или выше, загружающего Node v10.15.0, также указанный в поле React package.json Engines .

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

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

Шаг 4. Наслаждайтесь менее напряженным производственным развертыванием

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

Механизмы Node не решат всех ваших проблем, но они, по крайней мере, избавят вас от некоторых догадок (и непреднамеренных ошибок) в ваших производственных развертываниях. Для небольшого объема работы, необходимого для указания этого в конфигурации package.json , инвестиции сейчас могут сэкономить вам часы в будущем. Поверьте мне, это того стоит.

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

Спасибо за прочтение. Надеюсь, это убедит вас указать свои версии Node и механизмы NPM/Yarn в конфигурации package.json . Акции очень приветствуются!

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

Ссылки и дополнительные ресурсы:

Узлы | Кубернетес

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

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

Компоненты на узле включают кубелет, а среда выполнения контейнера и kube-прокси.

Менеджмент

Существует два основных способа добавления узлов на сервер API:

  1. Кублет на узле самостоятельно регистрируется в плоскости управления
  2. Вы (или другой пользователь-человек) вручную добавляете объект Node

После создания объекта Node, или kubelet на узле саморегистрируется, плоскость управления проверяет, является ли новый объект Node действительный.Например, если вы попытаетесь создать узел из следующего манифеста JSON:

  {
  "вид": "Узел",
  "апиВерсия": "v1",
  "метаданные": {
    "имя": "10.240.79.157",
    "метки": {
      "name": "мой-первый-k8s-узел"
    }
  }
}
  

Kubernetes создает внутри себя объект Node (представление). Kubernetes проверяет что kubelet зарегистрирован на сервере API, который соответствует metadata.name поле узла. Если узел исправен (т. е. все необходимые службы запущены), тогда он имеет право запускать Pod.В противном случае этот узел игнорируется для любой активности кластера. пока не станет здоровым.

Примечание:

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

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

Имя объекта Node должно быть допустимым DNS-имя поддомена.

Уникальность имени узла

Имя идентифицирует узел. Два узла не может иметь одно и то же имя одновременно.Kubernetes также предполагает, что ресурс с таким же название одного и того же объекта. В случае узла неявно предполагается, что экземпляр, использующий одно и то же имя будет иметь одинаковое состояние (например, сетевые настройки, содержимое корневого диска) и атрибуты, такие как метки узлов. Это может привести к несоответствия, если экземпляр был изменен без изменения его имени. Если узел должен быть значительно заменен или обновлен, существующий объект Node необходимо удалить с сервера API первый и повторно добавленный после обновления.

Самостоятельная регистрация узлов

Если флаг kubelet --register-node равен true (по умолчанию), kubelet попытается зарегистрироваться на сервере API. Это предпочтительный шаблон, используемый большинством дистрибутивов.

Для саморегистрации kubelet запускается со следующими параметрами:

  • --kubeconfig — Путь к учетным данным для аутентификации на сервере API.

  • --cloud-provider - Как связаться с облачным провайдером читать метаданные о себе.

  • --register-node — Автоматически регистрироваться на сервере API.

  • --register-with-taints — Зарегистрировать узел с заданным списком taints (через запятую =: ).

    Нет операции, если регистр-узел имеет значение false.

  • --node-ip - IP-адрес узла.

  • --node-labels — Метки для добавления при регистрации узла в кластере (см. ограничения по меткам, установленные Плагин допуска NodeRestriction).

  • --node-status-update-frequency — указывает, как часто kubelet отправляет статус своего узла на сервер API.

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

Примечание:

Как упоминалось в разделе уникальности имени узла, когда необходимо обновить конфигурацию узла, рекомендуется перерегистрировать узел с сервером API.Например, если kubelet перезапускается с новый набор --node-labels , но используется то же имя узла, изменение не вступают в силу, так как метки устанавливаются при регистрации узла.

Поды, уже запланированные на узле, могут работать неправильно или вызывать проблемы, если узел конфигурация будет изменена при перезапуске kubelet. Например, уже работает Pod может быть испорчен новыми метками, назначенными узлу, в то время как другие Поды, которые несовместимы с этим подом, будут запланированы на основе этого нового этикетка.Перерегистрация узла гарантирует, что все поды будут слиты и должным образом перепланировано.

Администрирование узла вручную

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

Если вы хотите создавать объекты Node вручную, установите флаг kubelet --register-node=false .

Вы можете изменять объекты Node независимо от настройки --register-node . Например, вы можете установить метки для существующего узла или пометить его как незапланированный.

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

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

Чтобы пометить узел как незапланированный, выполните:

См. Безопасное опустошение узла Больше подробностей.

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

Состояние узла

Состояние узла содержит следующую информацию:

Вы можете использовать kubectl для просмотра состояния узла и других сведений:

  kubectl описать узел 
  

Каждый раздел вывода описан ниже.

Адреса

Использование этих полей зависит от вашего облачного провайдера или конфигурации «голого железа».

  • HostName: имя хоста, сообщаемое ядром узла. Можно переопределить через kubelet --hostname-override параметр.
  • ExternalIP: Обычно это IP-адрес узла, маршрутизируемого извне (доступного из вне кластера).
  • InternalIP: обычно это IP-адрес узла, который маршрутизируется только внутри кластера.

Условия

Поле условий описывает состояние всех узлов Running .Примеры условий включают:

Условия узла и описание того, когда применяется каждое условие.
Состояние узла Описание
Готов Истинно , если узел исправен и готов принимать модули, Ложь , если узел неисправен и не принимает модули, и Неизвестно , если контроллер узла не получал известия от узла в последнем узле- период отсрочки монитора (по умолчанию 40 секунд)
Дискпрессуре Истинно , если существует давление на размер диска, т. е. если емкость диска мала; иначе Ложь
Давление памяти Истинно , если существует нехватка памяти узла, т. е. если памяти узла мало; иначе Ложь
ПИДДавление Истина , если существует нагрузка на процессы, т. е. если на узле слишком много процессов; иначе Ложь
Сеть недоступна Истина , если сеть для узла настроена неправильно, в противном случае Ложь

Примечание: Если вы используете инструменты командной строки для печати сведений об охраняемом узле, Условие включает Расписание отключено . SchedulingDisabled не является условием в Kubernetes API; вместо, оцепленные узлы помечены как Unschedulable в своих спецификациях.

В API Kubernetes состояние узла представлено как часть .status ресурса узла. Например, следующая структура JSON описывает работоспособный узел:

.
  "условия": [
  {
    "тип": "Готово",
    "статус": "Верно",
    "причина": "KubeletReady",
    "message": "kubelet публикует статус готовности",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]
  

Если состояние состояния Готов остается Неизвестно или Ложь дольше чем pod-eviction-timeout (аргумент, переданный kube-controller-manager), то срабатывает контроллер узла Выселение, инициированное API для всех модулей, назначенных этому узлу.Продолжительность тайм-аута вытеснения по умолчанию составляет пять минут . В некоторых случаях, когда узел недоступен, сервер API не может связаться с кублетом на узле. Решение об удалении модулей не может быть сообщено kubelet, пока связь с сервером API не будет восстановлена. В это время, модули, запланированные для удаления, могут продолжать работать на разделенном узле.

Контроллер узла не принудительно удаляет модули, пока не будет подтверждено, что они остановлены работает в кластере.Вы можете увидеть модули, которые могут работать на недоступном узле, как находясь в состоянии Terminating или Unknown . В случаях, когда Kubernetes не может сделать вывод из базовая инфраструктура, если узел навсегда покинул кластер, администратор кластера может потребоваться удалить объект узла вручную. Удаление объекта узла из Kubernetes приводит к все объекты Pod, работающие на узле, удаляются с сервера API и освобождают их имена.

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

См. Зараженные узлы по состоянию Больше подробностей.

Емкость и выделяемая

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

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

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

Информация

Описывает общую информацию об узле, такую ​​как версия ядра, Kubernetes версия (версия kubelet и kube-proxy), сведения о среде выполнения контейнера и какая операционная система, которую использует узел. kubelet собирает эту информацию с узла и публикует ее в API Кубернета.

Сердцебиение

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

Для узлов есть две формы тактов:

  • обновляет .status узла
  • Объекты аренды в пределах kube-node-lease пространство имен. Каждый узел имеет связанный с ним объект аренды.

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

kubelet отвечает за создание и обновление .status узлов, и для обновления соответствующих договоров аренды.

  • kubelet обновляет .status узла либо при изменении статуса или если не было обновлений для настроенного интервала. Интервал по умолчанию для .status обновления узлов составляют 5 минут, что намного дольше, чем 40 второй тайм-аут по умолчанию для недоступных узлов.
  • kubelet создает и обновляет объект Lease каждые 10 секунд. (интервал обновления по умолчанию). Обновления аренды происходят независимо от обновления узла .status . Если обновление Lease завершается неудачно, kubelet повторяет попытку. с использованием экспоненциальной отсрочки, которая начинается с 200 миллисекунд и ограничивается 7 секундами.

Узловой контроллер

Контроллер узла является Компонент плоскости управления Kubernetes, который управляет различными аспектами узлов.

Контроллер узла играет несколько ролей в жизни узла.Первый – это присвоение Блок CIDR для узла, когда он зарегистрирован (если назначение CIDR включено).

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

Третий следит за работоспособностью узлов.Контроллер узла ответственный за:

  • В случае, если узел становится недоступным, обновление условия NodeReady внутри узла .status . В этом случае контроллер узла устанавливает Состояние NodeReady на ConditionUnknown .
  • Если узел остается недоступным: срабатывание Выселение, инициированное API для всех модулей на недостижимом узле. По умолчанию контроллер узла ждет 5 минут между пометкой узла как ConditionUnknown и отправкой первое заявление о выселении.

Контроллер узла проверяет состояние каждого узла каждые --node-monitor-period секунд.

Ограничения частоты выселения

В большинстве случаев контроллер узла ограничивает скорость вытеснения до --node-eviction-rate (по умолчанию 0,1) в секунду, что означает, что он не будет выселять модули от более чем 1 узла за 10 секунд.

Поведение узла вытеснения изменяется, когда узел в данной зоне доступности становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне неработоспособны (условие NodeReady — ConditionUnknown или ConditionFalse ) в одновременно:

  • Если доля неработоспособных узлов не менее --unhealthy-zone-threshold (по умолчанию 0.55), то норма выселения снижается.
  • Если кластер мал (т.е. имеет меньше или равно --large-cluster-size-threshold узлов — по умолчанию 50), то выселение прекращается.
  • В противном случае скорость выселения снижается до --secondary-node-eviction-rate (по умолчанию 0,01) в секунду.

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

Основная причина распределения ваших узлов по зонам доступности заключается в том, что рабочая нагрузка может быть перенесена на здоровые зоны, когда одна зона выходит из строя. Следовательно, если все узлы в зоне неработоспособны, контроллер узла нормальная скорость --node-eviction-rate . Крайний случай, когда все зоны полностью неработоспособен (ни один из узлов в кластере не исправен).В таком В этом случае контроллер узла предполагает наличие какой-либо проблемы с подключением. между плоскостью управления и узлами и не выполняет никаких выселений. (Если произошел сбой и некоторые узлы снова появились, контроллер узла удалить модули из оставшихся неработоспособных или недоступных узлов).

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

Отслеживание емкости ресурсов

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

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

Топология узлов

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.16 [альфа]

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

Мягкое отключение узла

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.21 [бета]

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

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

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

Мягкое отключение узла управляется с помощью GracefulNodeShutdown особенность ворот, которая включено по умолчанию в 1.21.

Обратите внимание, что по умолчанию оба параметра конфигурации, описанные ниже, shutdownGracePeriod и shutdownGracePeriodCriticalPods установлены в ноль, таким образом, не активируя функцию отключения узла Graceful. Чтобы активировать эту функцию, необходимо правильно настроить два параметра конфигурации kubelet и установить ненулевые значения.

Во время корректного завершения работы kubelet завершает поды в два этапа:

  1. Завершить обычные модули, работающие на узле.
  2. Завершить критически важные модули работает на узле.

Функция плавного отключения узла настроена с двумя KubeletConfiguration варианты:

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

Например, если shutdownGracePeriod=30s и shutdownGracePeriodCriticalPods=10s , kubelet задержит выключение узла на 30 секунд. Во время отключения первые 20 (30-10) секунд будут зарезервированы. для изящного завершения обычных модулей, а последние 10 секунд будут зарезервировано для завершения критически важных модулей.

Примечание:

Когда модули были вытеснены во время корректного отключения узла, они помечаются как отключенные. Запуск kubectl get pods показывает статус выселенных pod'ов как Terminated . А kubectl description pod указывает, что pod был исключен из-за отключения узла:

  Причина: прекращено
Сообщение: Pod был прерван в связи с неизбежным отключением узла.
  

Мягкое отключение узла на основе приоритета пода

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.23 [альфа]

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

Функция Graceful Node Shutdown, как описано выше, закрывает модули в два этапа: некритические модули, за которыми следуют критические стручки.Если требуется дополнительная гибкость для явного определения порядка pod’ы во время выключения более гранулированным способом, изящно основанный на приоритете pod’ов можно использовать отключение.

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

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

Имя класса приоритета пода Значение класса приоритета пода
заказ-класс-а 100000
нестандартный класс-b 10000
нестандартный класс-c 1000
обычный/не установленный 0

В конфигурации kubelet настройки для shutdownGracePeriodByPodPriority могут выглядеть так:

Значение класса приоритета пода Период отключения
100000 10 секунд
10000 180 секунд
1000 120 секунд
0 60 секунд

Соответствующая конфигурация YAML конфигурации kubelet будет:

  shutdownGracePeriodByPodPriority:
  - приоритет: 100000
    shutdownGracePeriodSeconds: 10
  - приоритет: 10000
    shutdownGracePeriodSeconds: 180
  - приоритет: 1000
    shutdownGracePeriodSeconds: 120
  - приоритет: 0
    shutdownGracePeriodSeconds: 60
  

Из приведенной выше таблицы следует, что любой модуль со значением приоритета >= 100000 получит всего 10 секунд для остановки, любой модуль со значением >= 10000 и <100000 получит 180 секунд до остановки, любой модуль со значением >= 1000 и < 10000 получит 120 секунд для остановки.Наконец, у всех остальных модулей будет 60 секунд на остановку.

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

Значение класса приоритета пода Период отключения
100000 300 секунд
1000 120 секунд
0 60 секунд

В приведенном выше случае модули с custom-class-b попадут в одно и то же ведро. как custom-class-c для выключения.

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

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

Для использования этой функции необходимо включить GracefulNodeShutdownBasedOnPodPriority шлюз функции и настройка kubelet config ShutdownGracePeriodByPodPriority до желаемой конфигурации содержащие значения класса приоритета модуля и их соответствующие периоды отключения.

Управление памятью подкачки

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.22 [альфа]

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

Чтобы включить обмен на узле, шлюз функции NodeSwap должен быть включен на kubelet и флаг командной строки --fail-swap-on или failSwapOn настройка конфигурации должно быть установлено значение false.

Предупреждение: Когда функция подкачки памяти включена, данные Kubernetes, такие как содержимое Секретные объекты, которые были записаны в tmpfs, теперь можно было выгрузить на диск.

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

  подкачка памяти:
  swapBehavior: LimitedSwap
  

Доступные параметры конфигурации для swapBehavior :

  • LimitedSwap : рабочие нагрузки Kubernetes ограничены в том, насколько они могут обмениваться использовать.Рабочие нагрузки на узле, не управляемом Kubernetes, по-прежнему могут переключаться.
  • UnlimitedSwap : рабочие нагрузки Kubernetes могут использовать столько памяти подкачки, сколько они запрос, до ограничения системы.

Если конфигурация для memorySwap не указана, а шлюз функции включен, по умолчанию kubelet будет применять то же поведение, что и Параметр LimitedSwap .

Поведение параметра LimitedSwap зависит от того, работает ли узел с v1 или v2 контрольных групп (также называемых «cgroups»):

  • cgroupsv1: Рабочие нагрузки Kubernetes могут использовать любую комбинацию памяти и swap, вплоть до предела памяти модуля, если он установлен.
  • cgroupsv2: Рабочие нагрузки Kubernetes не могут использовать память подкачки.

Для получения дополнительной информации, помощи в тестировании и предоставления отзывов, пожалуйста, см. KEP-2400 и его дизайнерское предложение.

Что дальше

Rancher Docs: Управление шаблонами узлов

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

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

Создание шаблона узла из пользовательских настроек

  1. В настройках пользователя выберите Аватар пользователя > Шаблоны узлов .
  2. Щелкните Добавить шаблон .
  3. Выберите одного из доступных облачных провайдеров.Затем следуйте инструкциям на экране, чтобы настроить шаблон.

Результат: Шаблон настроен. Этот шаблон можно использовать позже при подготовке кластера пула узлов.

Обновление шаблона узла

  1. В настройках пользователя выберите Аватар пользователя > Шаблоны узлов .
  2. Выберите шаблон узла, который вы хотите изменить, и нажмите ⋮ > Изменить .

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

  3. Отредактируйте необходимую информацию и нажмите Сохранить .

Результат: Шаблон узла обновлен. Все пулы узлов, использующие этот шаблон узла, будут автоматически использовать обновленную информацию при добавлении новых узлов.

Клонирование шаблонов узлов

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

  1. В настройках пользователя выберите Аватар пользователя > Шаблоны узлов .
  2. Найдите шаблон, который хотите клонировать. Затем выберите ⋮ > Клонировать .
  3. Заполните оставшуюся часть формы.

Результат: Шаблон клонирован и настроен. Этот шаблон можно использовать позже при подготовке кластера пула узлов.

Удаление шаблона узла

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

Добавить комментарий

Ваш адрес email не будет опубликован.