Как проверить автоматический выключатель на исправность


Как проверить исправность автоматического выключателя при покупке

Вступление

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

Лабораторная проверка и проверка автоматов защиты по месту

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

В лаборатории можно точно проверить автомат защиты по трем основным характеристикам:

  • Номинальному току работы;
  • Току, при котором срабатывает защита;
  • Времени защитного срабатывания при перегрузке (уставка теплового расцепителя)  и коротком замыкании (уставка электромагнитного расцепителя).

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

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

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

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

Но опять-таки, этот вид проверки автомата защиты не подходит для проверки автомата при покупке. Что же делать?

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

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

Нет никакой гарантии, что купленный дорогой, шведский автомат ABB, будет на 100% исправным и выдержит, заявленные, 2000 срабатываний.

У меня в доме 10 лет назад бесплатно установили автоматы ИЭК, была такая программа, за это время срабатывали раз 20-30, и я не вижу причин их менять.

Нормативная ссылка

ГОСТ Р 50345-2010: Автоматические выключатели для защиты от сверхтоков бытового и аналогичного назначения. (Скачать напрямую в формате DOC)

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

  • Посмотрите нанесение маркировки на корпус автомата. Она должна быть явно заводской и четко различимой;
  • Проверьте правильность маркировки: название фирмы производителя должно быть написано латинскими буквами и точно соответствовать (побуквенно) логотипу производителя;

Например, маркировка автоматов фирмы ИЭК ранее наносилось русскими буквами. Такое обозначение устарело. С 2006 года автоматы этого производителя маркируются IEK. Отсюда вывод. Видим при покупке на автомате ИЭК, а не IEK, значит автомат старой партии. Или вместо ABB видим ABBB явная подделка.

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

Хочется отметить, что чаще всего я читал о подделке автоматов защиты ИЭК (IEK). Поэтому приведу отличительные признаки настоящего автомата защиты ИЭК.

Проверка автомата защиты IEK на подлинность

Вес автомата ИЭК;

  • ИЭК ВА 47-29 — 87 гр.
  • ИЭК ВА 47-29М вес 97 гр.
  • ИЭК ВА 47-60 вес 105 гр.

Для сравнения: Пачка сигарет весит 22-23 грамма. Тонкий смартфон-130-140 грамм, «толстый» смартфон весит 170-180 горамм.

Маркировка ИЭК обязательно латинская IEK;

Старая маркировка автомтов защиты ИЭК

Цвет полоски под логотипом IEK должен точно совпадать с цветом рычага взвода;

Новая, правильная маркировка автомата защиты ИЭКВелика вероятность поддельности автомата ИЭК

На корпусе должна быть нанесена информация об автомате и адрес сайта производителя методом штамповки;

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

Выводы

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

©Ehto.ru

Статьи по теме

  • Записи не найдены

Похожие посты:

  • Автоматы защиты, зачем они нужны, Рубрика Защита электрики
  • Расчет автоматов защиты, Рубрика Защита электрики
  • Плавкие предохранители: описание, назначение, типы, Рубрика Защита электрики
  • Основные электрические опасности в доме, Рубрика Защита электрики
  • УЗО противопожарной защиты, Рубрика УЗО
  • Назначение УЗО, Рубрика УЗО
  • Про УЗО простыми словами, Рубрика УЗО

5 советов по поиску и устранению неисправностей автоматических выключателей

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

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

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

Вот 5 советов, которые следует учитывать при проверке автоматического выключателя:

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

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

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

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

5. Проверьте автоматический выключатель на необходимое напряжение.
Прикоснитесь одним щупом тестера на 120–240 вольт к кончику «горячего» провода, а другим кончиком прикоснитесь к оголенному медному заземляющему проводу в сети. электрическая коробка. Используйте клемму заземления нейтрали, которая закреплена проводами заземления и нулевыми проводами для датчика.Вам нужно будет заменить автоматический выключатель, если вы обнаружите нужное значение напряжения.

Любые проблемы, связанные с вашим автоматическим выключателем, могут привести к серьезным проблемам в вашем доме и поставить под угрозу безопасность вашей семьи. Не рискуйте своей жизнью или имуществом, и наши специалисты из D&F Liquidators решат проблемы с подключением к электросети уже сегодня!

D&F Liquidators обслуживает потребности в строительных материалах для электротехники более 30 лет.Это международная информационная служба площадью 180 000 квадратных метров, расположенная в Хейворде, Калифорния. Он хранит обширный инвентарь электрических разъемов, кабелепроводов, автоматических выключателей, распределительных коробок, проводов, предохранительных выключателей и т. Д. Он закупает электрические материалы у ведущих компаний по всему миру. Компания также ведет обширный инвентарь взрывозащищенной продукции и современных решений для электрического освещения. Поскольку компания D&F закупает материалы оптом, она занимает уникальное положение, предлагая конкурентоспособную структуру ценообразования.Кроме того, он может удовлетворить самые взыскательные запросы и отгрузить материал в тот же день.

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

- v0.12.x | Kong

Осторожно! Вы просматриваете документацию по поиску устаревшей версии Kong Kong Gateway. Иди сюда для просмотра документации по последней версии. Приблизительное время прочтения: 12 минут

Введение

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

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

  • активных проверок , где конкретная конечная точка HTTP в цели периодически запрашивается, и здоровье цели определяется на основе ее ответ;

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

Здоровые и нездоровые цели

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

Либо активный зонд (при активных проверках работоспособности), либо прокси-запрос (при пассивных проверках работоспособности) производит данные, которые используются для определения здорова она или нездорова. Запрос может произвести TCP ошибка, тайм-аут или создание кода состояния HTTP. Основываясь на этом информации, средство проверки работоспособности обновляет ряд внутренних счетчиков:

  • Если возвращенный код состояния настроен как «работоспособен», он будет увеличить счетчик «Успехов» для цели и очистить все остальные счетчики;
  • Если не удается подключиться, он увеличивает счетчик «Ошибки TCP» за цель и сбросить счетчик «Успехов»;
  • Если время ожидания истекло, он увеличит счетчик времени ожидания. за цель и сбросить счетчик «Успехов»;
  • Если возвращенный код состояния настроен как «неработоспособный», он будет увеличить счетчик «HTTP-сбоев» для цели и сбросить счетчик «Успехов».

Если любой из счетчиков «сбоев TCP», «сбоев HTTP» или «тайм-аутов» достигает их настроенный порог, цель будет отмечена как неисправная.

Если счетчик «Успехов» достигнет настроенного порога, цель будет отмечен как здоровый.

Список кодов состояния HTTP «исправен» или «неработоспособен», а индивидуальные пороги для каждого из этих счетчиков настраиваются на на основе восходящего потока. Ниже у нас есть пример конфигурации для Объект Upstream, демонстрирующий значения по умолчанию для различных полей доступен для настройки проверок работоспособности.Описание каждого включено в справочную документацию по Admin API.

  { "name": "service.v1.xyz", "healthchecks": { "active": { «параллелизм»: 10, "здоровый": { "http_statuses": [200, 302], «интервал»: 0, «успехов»: 0 }, "http_path": "/", «тайм-аут»: 1, "нездоровый": { "http_failures": 0, "http_statuses": [429, 404, 500, 501, 502, 503, 504, 505], «интервал»: 0, "tcp_failures": 0, «таймауты»: 0 } }, "пассивный": { "здоровый": { "http_statuses": [200, 201, 202, 203, 204, 205, 206, 207, 208, 226, 300, 301, 302, 303, 304, 305, 306, 307, 308], «успехов»: 0 }, "нездоровый": { "http_failures": 0, "http_statuses": [429, 500, 503], "tcp_failures": 0, «таймауты»: 0 } } }, «слотов»: 10 }  

Если все цели восходящего потока неисправны, Kong ответит на запросы. к восходящему потоку с 503 Service Unavailable .

Примечание:

  1. проверки работоспособности работают только на активных целях и не изменить активный статус цели в базе данных Kong.
  2. нездоровых целей не будут удалены из балансировщика нагрузки и, следовательно, будут не влияют на компоновку балансировщика при использовании алгоритма хеширования (они просто будут пропущены).
  3. Предостережения относительно DNS и балансировки также относятся к проверкам здоровья. Если для целей используются имена хостов, сделайте убедитесь, что DNS-сервер всегда возвращает полный набор IP-адресов для имени, и не ограничивает ответ. Невыполнение этого требования может привести к здоровью. проверки не выполняются.

Виды проверок здоровья

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

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

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

Вернуться к оглавлению

Пассивные проверки состояния (автоматические выключатели)

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

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

  $ curl -i -X ​​POST http: // localhost: 8001 / upstreams / my_upstream / target / 10.1.2.3: 1234 / здоровы HTTP / 1.1 204 Нет содержимого  

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

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

Вернуться к оглавлению

Сводка плюсов и минусов

  • Активные проверки работоспособности могут автоматически повторно активировать цель в кольцевой балансир, как только он снова станет здоровым. Пассивные проверки работоспособности не могут.
  • Пассивные проверки работоспособности не создают дополнительного трафика для цель. Активные проверки работоспособности делать.
  • Активному средству проверки работоспособности требуется известный URL-адрес с надежным ответом о состоянии в целевом объекте, который будет настроен как конечная точка проверки (которая может быть как просто как "/" ).Пассивные проверки работоспособности не требуют такой настройки.
  • Предоставляя настраиваемую конечную точку зондирования для активного средства проверки работоспособности, приложение может определять свои собственные показатели работоспособности и выдавать статус код, который будет использовать Kong. Даже если цель продолжает служить трафик, который выглядит здоровым для пассивной проверки работоспособности, он сможет ответить на активный зонд отказом status, по сути, с просьбой освободить вас от приема нового трафика.

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

Включение и отключение проверок работоспособности

Включение активных проверок работоспособности

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

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

  • healthchecks.active.http_path - путь, который следует использовать при отправка HTTP-запроса GET к цели. Значение по умолчанию - /.
  • healthchecks.active.timeout - Предел тайм-аута подключения для HTTP-запрос GET зонда.Значение по умолчанию - 1 секунда.
  • healthchecks.active.concurrency - Количество целевых объектов для одновременной проверки при активных проверках работоспособности.

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

  • healthchecks.active.healthy.interval - Интервал между активным здоровьем проверяет наличие здоровых целей (в секундах). Нулевое значение указывает, что активный зонды для здоровых целей не должны выполняться.
  • проверка работоспособности.active.unhealthy.interval - Интервал между активным здоровьем проверяет наличие нездоровых целей (в секундах). Нулевое значение указывает, что активный зонды на нездоровые цели не должны выполняться.

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

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

  • healthchecks.active.healthy.successes - Количество успехов в активных зонды (как определено в healthchecks.active.healthy.http_statuses ) для рассмотрения цель здоровая.
  • healthchecks.active.unhealthy.tcp_failures - Количество сбоев TCP в активные зонды, чтобы считать цель нездоровой.
  • healthchecks.active.unhealthy.timeouts - Количество тайм-аутов в активном состоянии зонды, чтобы считать цель нездоровой.
  • healthchecks.active.unhealthy.http_failures - Количество сбоев HTTP в активные зонды (как определено в healthchecks.active.unhealthy.http_statuses ) на Считайте цель нездоровой.

Включение пассивных проверок работоспособности

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

  • проверка работоспособности.passive.healthy.successes - Количество успехов в прокси трафик (как определено в healthchecks.passive.healthy.http_statuses ) на Считайте цель здоровой, по результатам пассивных проверок работоспособности. Это необходимо быть положительным, когда включены пассивные проверки, так что здоровый трафик сбрасывает нездоровые счетчики.
  • healthchecks.passive.unhealthy.tcp_failures - Количество сбоев TCP в прокси-трафик, чтобы считать цель нездоровой, что определяется пассивным здоровьем чеки.
  • healthchecks.passive.unhealthy.timeouts - Количество тайм-аутов в прокси трафик, чтобы считать цель нездоровой, по данным пассивных проверок работоспособности.
  • healthchecks.passive.unhealthy.http_failures - Количество ошибок HTTP в прокси-трафик (как определено в healthchecks.passive.unhealthy.http_statuses ) считать цель нездоровой по результатам пассивных проверок работоспособности.

Отключение проверок работоспособности

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

Таким образом, чтобы полностью отключить активные проверки работоспособности для восходящего потока, вы необходимо установить обе проверки работоспособности .active.healthy.interval и healthchecks.active.unhealthy.interval с по 0 .

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

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

Вернуться к оглавлению

.

Высокодоступных микросервисов с проверками работоспособности и автоматическими выключателями

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

Однако микросервисы также создают проблемы, включая более сложную инфраструктуру для управления. У вас есть больше сервисов для мониторинга доступности и производительности.Также нелегко сбалансировать нагрузку и устранить отказы для поддержания высокой доступности. Если ваши службы отслеживают состояние, вам необходимо поддерживать постоянные соединения между клиентами и экземплярами. Большинство разработчиков API предпочли бы, чтобы система управляла этими сложностями инфраструктуры, чтобы они могли сосредоточиться на бизнес-логике.

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

Введение в балансировку нагрузки

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

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

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

Важные типы балансировщиков нагрузки

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

Балансировка нагрузки сервера доменных имен (DNS)

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

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

Недостатком является то, что клиенты часто кэшируют IP-адрес в течение периода времени, известного как время жизни (TTL). Если TTL составляет минуты или часы, удаление нездоровых хостов или перебалансировка нагрузки может оказаться непрактичным. Если он установлен на секунды, вы можете быстрее восстанавливаться, но это также создает дополнительный трафик DNS и задержку. Этот подход лучше использовать с хостами, которые обладают высокой производительностью и могут быстро восстанавливаться, или во внутренних сетях, где вы можете тщательно контролировать DNS.

Round robin

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

Кольцевой балансировщик

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

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

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

Проверки работоспособности и автоматические выключатели повышают доступность

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

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

При активных проверках работоспособности балансировщик нагрузки периодически «зондирует» вышестоящие серверы, отправляя специальный запрос проверки работоспособности. Если подсистеме балансировки нагрузки не удается получить ответ от вышестоящего сервера или если ответ не соответствует ожиданиям, он отключает трафик на сервер. Например, обычно требуется, чтобы ответ от сервера содержал HTTP-код 200 OK. Если время ожидания сервера истекло или в ответ выдается ошибка сервера 500, значит, он неисправен.

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

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

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

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

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

Автоматические выключатели

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

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

Что такое Конг?

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

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

Уникальным преимуществом Kong является то, что как активные, так и пассивные проверки работоспособности предлагаются бесплатно в Community Edition (CE). Nginx предлагает пассивные проверки работоспособности в версии для сообщества, но активные проверки здоровья включены только в платную версию Nginx Plus. Amazon Elastic Load Balancers (ELB) не поддерживает пассивные проверки. Кроме того, в зависимости от вашего использования, это может стоить больше, чем запуск вашего собственного экземпляра Kong. Зонды жизнеспособности Kubernetes предлагают только активные проверки.

Nginx Amazon ELB Kubernetes Kong CE
Активные проверки X Plus только X X

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

Посмотрите на это в действии

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

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

Шаг 1: Добавьте два тестовых хоста

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

Сначала давайте создадим наш контейнер для здоровья. Он ответит "Hello World!" Мы настроим это с помощью статического файла и подключим его в html-каталог нашего контейнера.

$ mkdir host1 $ echo "Привет, мир!" & gt; host1 / index.html $ docker run --name host1 -v ~ / host1: / usr / share / nginx / html: ro -p 9090: 80 -d nginx $ curl localhost: 9090 Привет мир!

$ mkdir host1

$ echo "Hello World!" & gt; host1 / index.html

$ docker run --name host1 -v ~ / host1: / usr / share / nginx / html: ro -p 9090: 80 -d nginx

$ curl localhost: 9090

Hello World!

А теперь давайте создадим контейнер с нездоровой пищей.Мы настроим Nginx для ответа с ошибкой сервера 500. Сначала скопируйте конфигурацию nginx по умолчанию.

$ docker cp host1: /etc/nginx/conf.d/default.conf ~

$ docker cp host1: /etc/nginx/conf.d/default.conf ~

Затем отредактируйте местоположение, чтобы вернуть ошибку 500.

$ vim ~ / default.conf место расположения / { return 500 ‘Error \ n’; корень / usr / share / nginx / html; index index.html index.htm; }

$ vim ~ / default.conf

location / {

return 500 ‘Error \ n’;

root / usr / share / nginx / html;

index index.html index.htm;

}

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

$ docker run --name host2 -v ~ / default.conf: /etc/nginx/conf.d/default.conf -p 9091: 80 -d nginx $ curl -i локальный: 9091 Ошибка

$ docker run --name host2 -v ~ / default.conf: /etc/nginx/conf.d/default.conf -p 9091: 80 -d nginx

$ curl -i localhost: 9091

Ошибка

Шаг 2: Установить Kong

Можно установить

Kong в самых разных средах. Мы будем следовать инструкциям Docker, поскольку их относительно легко протестировать на рабочем столе разработчика.
Во-первых, нам нужна база данных, в которой Kong может хранить свои настройки. Будет использовать Postgres, поскольку в Docker легко настроить тестовый контейнер.

$ docker run -d --name kong-database \ -p 5432: 5432 \ -e "POSTGRES_USER = kong" -e "POSTGRES_DB = kong" \ постгрес: 9.4

$ docker run -d --name kong-database \

-p 5432: 5432 \

-e "POSTGRES_USER = kong"

-e "POSTGRES_DB = kong" \

postgres: 9.4

Затем нам нужно инициализировать базу данных.

$ docker run --rm \ --link база данных kong: база данных kong \ -e "KONG_DATABASE = postgres" \ -e "KONG_PG_HOST = база данных конг" \ -e "KONG_CASSANDRA_CONTACT_POINTS = kong-database" \ kong: последние миграции конг

$ docker run --rm \

--link kong-database: kong-database \

-e "KONG_DATABASE = postgres" \

-e "KONG_PG_HOST = kong -database "\

-e" KONG_CASSANDRA_CONTACT_POINTS = kong-database "\

kong: последние миграции конга вверх

Теперь давайте запустим контейнер Kong.Эти параметры используют порты по умолчанию и подключаются к нашей базе данных Cassandra.

$ docker run -d --name kong \ --link база данных kong: база данных kong \ -e "KONG_DATABASE = postgres" \ -e "KONG_PG_HOST = база данных конг" \ -e "KONG_CASSANDRA_CONTACT_POINTS = kong-database" \ -e "KONG_PROXY_ACCESS_LOG = / dev / stdout" \ -e "KONG_ADMIN_ACCESS_LOG = / dev / stdout" \ -e "KONG_PROXY_ERROR_LOG = / dev / stderr" \ -e "KONG_ADMIN_ERROR_LOG = / dev / stderr" \ -e "KONG_ADMIN_LISTEN = 0.0.0.0: 8001 "\ -e "KONG_ADMIN_LISTEN_SSL = 0.0.0.0: 8444" \ -p 8000: 8000 \ -p 8443: 8443 \ -p 8001: 8001 \ -p 8444: 8444 \ kong: последний

$ docker run -d --name kong \

--link kong-database: kong-database \

-e "KONG_DATABASE = postgres" \

-e "KONG_PG_HOST = kong -database "\

-e" KONG_CASSANDRA_CONTACT_POINTS = база данных kong "\

-e" KONG_PROXY_ACCESS_LOG = / dev / stdout "\

-e" KONG_ADMIN_ACCESS_LOG2 "/ dev / dev / ACCESS_LOG2_ / dev_ACCESS_LOG2_ / dev_ACCESS_LOG2_ / dev dev / stderr "\

-e" KONG_ADMIN_ERROR_LOG = / dev / stderr "\

-e" KONG_ADMIN_LISTEN = 0.0.0.0: 8001 "\

-e" KONG_ADMIN_LISTEN_SSL = 0.0.0.0: 8444 "\

-p 8000: 8000 \

-p 8443: 8443 \

-p 8001: 8001 \

-p 8444 : 8444 \

kong: последний

Убедитесь, что Kong работает на порту 8001 и выдает ответ 200 «ОК». Это означает, что он работает.

$ curl -i локальный: 8001 / apis HTTP / 1.1 200 OK

$ curl -i localhost: 8001 / apis

HTTP / 1.1 200 OK

Шаг 3: Настройте Kong для использования наших тестовых хостов

Теперь мы хотим подключить Kong к нашим тестовым хостам. Первый шаг - настройка API в Kong. «API» - это просто исторический термин, поскольку Kong может балансировать нагрузку любого HTTP-трафика, включая запросы веб-сервера. Я собираюсь называть наш API «mytest», так как его легко запомнить. Я также устанавливаю тайм-аут соединения на 5 секунд, потому что я слишком нетерпелив, чтобы ждать 60 секунд по умолчанию. Если вы хотите узнать больше о создании API, см. Документацию Kong.

$ curl -i -X ​​POST \ --url http: // localhost: 8001 / apis / \ --data 'name = mytest' \ --data 'hosts = mytest.com' \ --data 'upstream_url = http: // mytest / ' --data 'upstream_connect_timeout = 5000'

$ curl -i -X ​​POST \

--url http: // localhost: 8001 / apis / \

--data 'name = mytest' \

--data 'hosts = mytest.com' \

--data 'upstream_url = http: // mytest / '

--data 'upstream_connect_timeout = 5000'

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

$ curl -i -X ​​POST http: // localhost: 8001 / upstreams / \ --data 'name = mytest' \ --data 'healthchecks.active.healthy.interval = 5' \ --data 'healthchecks.active.unhealthy.interval = 5' \ --data 'healthchecks.active.unhealthy.http_failures = 2' \ --data 'healthchecks.active.healthy.успехи = 2 '

$ curl -i -X ​​POST http: // localhost: 8001 / upstreams / \

--data' name = mytest '\

--data' healthchecks.active.healthy .interval = 5 '\

--data' healthchecks.active.unhealthy.interval = 5 '\

--data' healthchecks.active.unhealthy.http_failures = 2 '\

--data' healthchecks.active. Healthy.successes = 2 '

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

$ curl -i -X ​​POST http: // localhost: 8001 / upstreams / mytest / target --data 'target = 192.168.0.8: 9090' $ curl -i -X ​​POST http: // localhost: 8001 / upstreams / mytest / target --data 'target = 192.168.0.8: 9091'

$ curl -i -X ​​POST http: // localhost : 8001 / upstreams / mytest / target --data 'target = 192.168.0.8: 9090'

$ curl -i -X ​​POST http: // localhost: 8001 / upstreams / mytest / target --data 'target = 192.168.0.8: 9091 '

Kong теперь должен быть полностью настроен. Мы можем проверить, что он работает правильно, отправив запрос GET на порт прокси Kong, который по умолчанию равен 8000. Мы передадим заголовок, идентифицирующий хост, который привязан к нашему API. Мы должны получить ответ от нашего сервера Nginx: «Привет!»

$ curl -H "Хост: mytest.com" localhost: 8000 Привет мир!

$ curl -H "Host: mytest.com" localhost: 8000

Hello World!

Шаг 4. Проверка работоспособности

Вы заметите, что Kong не возвращает ошибку 500, сколько бы раз вы ее ни вызывали.Так что случилось с host2? Вы можете проверить журналы kong, чтобы увидеть статус проверки работоспособности.

$ докер журналы конг | grep healthcheck 2018/02/21 20:00:05 [предупреждение] 45 # 0: * 17672 [lua] healthcheck.lua: 957: log (): [healthcheck] (mytest) нездоровое приращение HTTP (1/2) < / b> для 172.31.18.188:9091, контекст: ngx.timer, клиент: 172.17.0.1, сервер: 0.0.0.0:8001 2018/02/21 20:00:10 [предупреждение] 45 # 0: * 17692 [lua] healthcheck.lua: 957: log (): [healthcheck] (mytest) нездоровое приращение HTTP (2/2) < / b> для 172.31.18.188: 9091, контекст: ngx.timer, клиент: 172.17.0.1, сервер: 0.0.0.0:8001

$ docker logs kong | grep healthcheck

2018/02/21 20:00:05 [предупреждение] 45 # 0: * 17672 [lua] healthcheck.lua: 957: log (): [healthcheck] (mytest) нездоровое приращение HTTP (1 / 2) для 172.31.18.188:9091, контекст: ngx.timer, клиент: 172.17.0.1, сервер: 0.0.0.0:8001

2018/02/21 20:00:10 [предупреждение] 45 # 0: * 17692 [lua] healthcheck.lua: 957: log (): [healthcheck] (mytest) нездоровое приращение HTTP (2/2) для 172.31.18.188: 9091, контекст: ngx.timer, клиент: 172.17.0.1, сервер: 0.0.0.0:8001

Kong автоматически обнаруживает отказавший хост, увеличивая значение счетчика неработоспособности. Когда он достигает порога 2, он разрывает цепь и направляет запросы на исправный хост.
Затем давайте вернем конфигурацию Nginx обратно, чтобы он возвращал код 200 OK. Мы должны увидеть, что Kong признал его работоспособным и теперь возвращает страницу Nginx по умолчанию. Возможно, вам придется запустить его несколько раз, чтобы увидеть host2, поскольку Kong не переключает все остальные запросы.

$ docker cp host1: /etc/nginx/conf.d/default.conf ~ $ docker контейнер перезапуск host2 $ curl -H "Хост: mytest.com" localhost: 8000 & lt;! DOCTYPE html & gt; & lt; html & gt; & lt; head & gt; & lt; title & gt; Добро пожаловать в nginx! & lt; / title & gt;

$ docker cp host1: /etc/nginx/conf.d/default.conf ~

$ docker container restart host2

$ curl -H "Host: mytest.com" localhost: 8000

& lt ;! DOCTYPE html & gt;

& lt; html & gt;

& lt; head & gt;

& lt; title & gt; Добро пожаловать в nginx! & Lt; / title & gt;

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

Заключение

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

Разверните устройства проверки работоспособности и автоматические выключатели с помощью Kong

.

Как сбросить автоматический выключатель

В большинстве домов используются автоматические выключатели, отключающие питание комнаты при возникновении электрической перегрузки или короткого замыкания. Автоматический выключатель удобно отключает питание только проблемной цепи, не отключая все в доме [источник: Barnhart, Carey, Hamilton, Prestly, Strong]

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

Объявление

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

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

Вот как найти проблему:

  • Проверьте короткое замыкание, включив каждый свет. Если прерыватель остается включенным, осторожно подключите каждое устройство. Если автоматический выключатель срабатывает, когда вы что-то подключаете, вы нашли источник проблемы. Отключите устройство и перезапустите прерыватель. Вы можете проверить подозрение на короткое замыкание, проверив шнур питания на наличие расплавленной изоляции. Также проверьте вилку и розетку на запах гари или обугливания.
  • Проверьте отсутствие перегрузки, подключив все и включив все.Если срабатывает прерыватель, либо выключите некоторые источники энергии, такие как кондиционер или обогреватели, либо подключите их к розетке другой цепи [источник: сделай сам].
.

Смотрите также