Вопросы Теги

haproxy и keepalived на Amazon EC2

iotop (ссылка) для начинающего ;) Я не видел, что Вы отправляете вывод его.

1: Я испытал почти ту же ситуацию с регистрирующейся файловой системой и atime - однако с большим количеством записей.

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

2: Я предполагаю, что этот раздел не является частью просто восстанавливающего массива RAID, не так ли?

3: Если у Вас есть много очень маленьких файлов (намного меньший, чем фактическое блочное устройство blocksize и/или файловая система blocksize), и Вы читаете те маленькие файлы, Вы заканчиваете тем, что читали все блоки из системы, и большинство тех блоков ни из чего не будет считано.

4: Если ничто не помогает выше, можно всегда получать список файлов, к которым получают доступ путем выполнения 

echo 1 > /proc/sys/vm/block_dump

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

5
задан 2 April 2013 в 00:05
1 ответ

Я также использую haproxy для нашей балансировки нагрузки, потому что на момент разработки Amazon Elastic Load Balancing (ELB) не поддерживал серверы в VPC. У них есть эта функция сейчас (я считаю, что не использовал ее, так как haproxy отлично работает для нас).

Мы вообще не пробовали keepalived по двум причинам:

  1. Мы сомневались, что сможем изменить частный IP-адрес на сервере, не используя AWS (консоль или API). Кроме того, AWS не позволяет двум серверам в одном VPC иметь один и тот же внутренний IP-адрес.
  2. Нам требовалась установка в нескольких зонах доступности для обеспечения высокой доступности. Внутренний IP-адрес сервера в VPC основан на подсети VPC, и каждая подсеть может принадлежать только 1 VPC. Следовательно, мы не можем иметь два хоста в двух разных зонах доступности в одной подсети.

Поэтому мы реализовали следующее решение:

  • Настройте haproxy на двух серверах (по одному в каждой зоне доступности).
  • Также разделите наши внутренние (например, веб) серверы на две или более зоны доступности.
  • Установите эластичный IP-адрес на один из серверов haproxy (в «основном» AZ по нашему выбору). Это виртуальный IP-адрес, к которому будут обращаться веб-клиенты.
  • Отслеживайте виртуальный IP-адрес из внешнего источника (за пределами региона AWS). В случае сбоя (экземпляр или вся зона доступности) переназначьте эластичный IP-адрес вторичному серверу haproxy (при условии, что на этом хосте проходят тесты).
    • Ссылка EIP: http://aws.amazon.com/articles/1346
    • Примечание. На данный момент мы делаем это вручную (требуется очень редко - один или два раза в год на случай отключения АЗ), но это можно легко создать с помощью сценария с использованием API AWS и заставить сервер мониторинга запускать переключение в случае сбоя.
    • Также обратите внимание, что существует стоимость переназначения EIP (0,10 доллара США за переназначение из 100 бесплатных повторных отображений в месяц). Поскольку сбои в зоне доступности являются относительно редкими, я не думаю, что это будет проблемой.

Один из потенциальных рисков заключается в том, что во время серьезных сбоев AWS мы иногда замечали, что консоль AWS и API начинают отказывать (полностью или чаще, чем обычный). Это может повлиять на попытки переназначить эластичный IP-адрес.

2
ответ дан 3 December 2019 в 01:58

Теги

Похожие вопросы