Как изящно завершить работу или удалить экземпляры AWS из группы ELB - PullRequest
Новая
       21

Как изящно завершить работу или удалить экземпляры AWS из группы ELB

23 голосов
/ 05 октября 2011

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

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

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

Мое приложение - это node.js, работающее на Ubuntu.У меня также работает какое-то специальное программное обеспечение, поэтому я предпочитаю не использовать многие PAAS, предлагающие хостинг node.js.

Спасибо за любые подсказки.

Ответы [ 6 ]

16 голосов
/ 09 апреля 2014

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

Чтобы включить это поведение, перейдите на вкладку Instances вашего loadbalancer и измените поведение Connection Draining.

16 голосов
/ 11 октября 2011

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

Обзор процесса

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

  1. Блокируйте новые HTTP-соединения с nodeX, но продолжайте разрешать существующие соединения
  2. Дождитесь истечения существующих соединений, либо отслеживая существующие соединения с вашим приложением, либо предоставляя «безопасное» количествовремя.
  3. Инициируйте завершение работы на экземпляре nodeX EC2, используя API-интерфейс EC2 напрямую или абстрактные сценарии.

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

Предположения, которые необходимо проверить

Мы знаем, что ELB удаляет нездоровые экземпляры из своего пула Я ожидаю, что это будет изящно, так что:

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

возможные тестовые случаи:

  • Fire HTTP-соединения на ELB (например, от завиткаscript) регистрация результатов во время скриптового открытия закрытия одного из узлов HTTP-портов.Вам нужно будет поэкспериментировать, чтобы найти приемлемое количество времени, которое позволяет ELB всегда определять изменение состояния.
  • Поддерживать длительный сеанс HTTP (например, загрузку файла), при этом блокируя новые соединения HTTP, следует надеяться, что длинный сеанс долженпродолжить.

1.Как заблокировать HTTP-соединения

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

Например, таблицы IP: 

iptables -A INPUT -j DROP -p tcp --syn --destination-port <web service port>
7 голосов
/ 03 ноября 2011

Рекомендуемый способ распределения трафика с вашего ELB - это иметь равное количество экземпляров в нескольких зонах доступности.Например:

ELB

  • Экземпляр 1 (us-east-a)
  • Экземпляр 2 (us-east-a)
  • Экземпляр3 (us-east-b)
  • Экземпляр 4 (us-east-b)

Теперь есть два представляющих интерес ELB API, которые позволяют вам программно (или черезпанель управления) отсоединение экземпляров:

  1. Отмена регистрации экземпляра
  2. Отключение зоны доступности (которая впоследствии отключает экземпляры в этой зоне)

Руководство разработчика ELB содержит раздел, в котором описываются эффекты отключения зоны доступности.Примечание в этом разделе представляет особый интерес:

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

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

Приведенная выше «теория» нуждается в подробном тестировании или подтверждении от облачного инженера Amazon.

4 голосов
/ 04 октября 2012

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

  1. Сервер может потерять питание.
  2. Аппаратный сбой приводит к сбою сервера.
  3. Соединение может быть закрыто из-за проблем с сетью.
  4. Клиент теряет интернет или Wi-Fi.

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

2 голосов
/ 23 декабря 2014

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

Вам необходим экземпляр ec2 с предоставленным сервером Python за ELB. 

from flask import Flask
import time

app = Flask(__name__)

@app.route("/")
def index():
    return "ok\n"

@app.route("/wait/<int:secs>")
def wait(secs):
    time.sleep(secs)
    return str(secs) + "\n"

if __name__ == "__main__":
    app.run(
        host='0.0.0.0',
        debug=True)

Затем выполните следующий сценарий изместная рабочая станция в направлении ELB. 

#!/bin/bash

which jq >> /dev/null || {
   echo "Get jq from http://stedolan.github.com/jq"
}

# Fill in following vars
lbname="ELBNAME"
lburl="http://ELBURL.REGION.elb.amazonaws.com/wait/30"
instanceid="i-XXXXXXX"

getState () {
    aws elb describe-instance-health \
        --load-balancer-name $lbname \
        --instance $instanceid | jq '.InstanceStates[0].State' -r
}

register () {
    aws elb register-instances-with-load-balancer \
        --load-balancer-name $lbname \
        --instance $instanceid | jq .
}

deregister () {
    aws elb deregister-instances-from-load-balancer \
        --load-balancer-name $lbname \
        --instance $instanceid | jq .
}

waitUntil () {
    echo -n "Wait until state is $1"
    while [ "$(getState)" != "$1" ]; do
        echo -n "."
        sleep 1
    done
    echo
}

# Actual Dance
# Make sure instance is registered. Check latency until node is deregistered

if [ "$(getState)" == "OutOfService" ]; then
    register >> /dev/null
fi

waitUntil "InService"

curl $lburl &
sleep 1

deregister >> /dev/null

waitUntil "OutOfService"
1 голос
/ 04 октября 2012

Предостережение, которое не обсуждалось в существующих ответах, состоит в том, что ELB также используют записи DNS с 60-секундными TTL для балансировки нагрузки между несколькими узлами ELB (к каждому из которых прикреплен один или несколько ваших экземпляров).

Это означает, что если у вас есть экземпляры в двух разных зонах доступности, у вас, вероятно, есть два IP-адреса для вашего ELB с TTL 60 с на их записях A.Когда вы удаляете последние экземпляры из такой зоны доступности, ваши клиенты «могут» по-прежнему использовать старый IP-адрес не менее минуты - неисправные преобразователи DNS могут вести себя гораздо хуже.

В другой раз ELB носят несколько IP-адресов ита же проблема возникает, когда в одной зоне доступности у вас очень большое количество экземпляров, что слишком много для одного сервера ELB.ELB в этом случае также создаст другой сервер и добавит его IP в список записей A с TTL 60 секунд.

...