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

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

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

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

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

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

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

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

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

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

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

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

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

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

iptables -A INPUT -j DROP -p tcp --syn --destination-port <web service port>

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

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

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

ELB

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

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

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

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

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

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

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

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

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

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

Не могу комментировать причину своей низкой репутации. Вот несколько созданных мной фрагментов, которые могут быть очень полезны для кого-то там. Он использует инструмент 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"

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

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

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