Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Для масштабирования таких балансировщиков нагрузки как Nginx и HAproxy необходима разработка своих скриптов и образов системы
nginx.org/en/docs/howto_setup_development_environment_on_ec2.html
Хотелось бы подробнее узнать за счёт чего обеспечивается отказоустойчивость ELB. Ведь эта подсистема является узким местом для всей вышеописанной мощности Amazon. Используются ли географически распределённые дата-центры для одного моего конкретного IP, anycast, что-то ещё?
Имея среднестатистическое веб-приложение, у нас есть DNS -> «nginx/elb» -> «приложение».
— Если что-то случится с «приложением», то мы практически моментально можем переключиться на резервный дата-центр дёрнув «nginx/elb».
— Если умер «nginx/elb», то дело плохо ведь быстро переключить DNS невозможно. Он кешируется везде где только можно, причём указанный TTL не всегда соблюдается. Любой DNS. Даже тот, что под брендом Amazon.
— Если умер DNS… Ну и пусть, у нас ведь nx-серверов больше одного прописано.
Сейчас использую связку DNS (5 nx-серверов) + nginx (балансировщик + failover ip на другой ДЦ) + приложение (там все серьёзно в плане масштабирования и отказоустойчивости).
И, собственно, вопрос: Чем отказоустойчивее Amazon по сравнению с моей системой?
Имея среднестатистическое веб-приложение, у нас есть DNS -> «nginx/elb» -> «приложение».
— Если что-то случится с «приложением», то мы практически моментально можем переключиться на резервный дата-центр дёрнув «nginx/elb».
— Если умер «nginx/elb», то дело плохо ведь быстро переключить DNS невозможно. Он кешируется везде где только можно, причём указанный TTL не всегда соблюдается. Любой DNS. Даже тот, что под брендом Amazon.
— Если умер DNS… Ну и пусть, у нас ведь nx-серверов больше одного прописано.
Сейчас использую связку DNS (5 nx-серверов) + nginx (балансировщик + failover ip на другой ДЦ) + приложение (там все серьёзно в плане масштабирования и отказоустойчивости).
И, собственно, вопрос: Чем отказоустойчивее Amazon по сравнению с моей системой?
— ELB не использует один фиксированный IP, он использует пул адресов и DNS CNAME. И для работы с ним используется соответственно не IP, а доменное имя.
— ELB может работать между зонами доступности Amazon, но только в пределах одного региона
Route 53 работает между регионами, имеет встроенную проверку состояния и работает, так же как и ваши 5 DNS серверов. А проблема кэширования на уровне DNS клиента, особенно в Windows, может быть в любом случае.
Amazon, конечно, не является единственно правильным вариантом, и имеет свои недостатки. Самому свою систему можно настроить более гибко и более точно для своих конкретных целей. Все дело в сроках реализации конкретной схемы и в стоимости. На Amazon это всё можно внедрить быстрее и это может обойтись дешевле, чем использование своих датацентров или аренда серверов.
— ELB может работать между зонами доступности Amazon, но только в пределах одного региона
Route 53 работает между регионами, имеет встроенную проверку состояния и работает, так же как и ваши 5 DNS серверов. А проблема кэширования на уровне DNS клиента, особенно в Windows, может быть в любом случае.
Amazon, конечно, не является единственно правильным вариантом, и имеет свои недостатки. Самому свою систему можно настроить более гибко и более точно для своих конкретных целей. Все дело в сроках реализации конкретной схемы и в стоимости. На Amazon это всё можно внедрить быстрее и это может обойтись дешевле, чем использование своих датацентров или аренда серверов.
То есть отказоустойчивость каждого конкретного ip-адреса ELB обеспечивается за счёт аналога DNS Round Robin на уровне Route 53? Правильно понимаю?
Там на самом деле всё немного сложнее. По умолчанию пул ELB IP адресов содержит только один IP на каждую зону доступности, для которой он сконфигурирован. При увеличении сетевой нагрузки в пул добавляются дополнительные IP для обеспечения необходимой пропускной способности. IP в пуле не фиксированы и могут меняться. При DNS запросе выдается IP из пула, скорее всего по Round Robin и в соответствии доступностью зон. Сам Amazon рекомендует использовать Route 53 над ELB для устранения проблемы с изменением IP в пуле и уменьшения TTL.
А что на самом деле стоит за каждым IP адресом ELB они не раскрывают, во всяком случае, я такой информации пока не нашел.
А что на самом деле стоит за каждым IP адресом ELB они не раскрывают, во всяком случае, я такой информации пока не нашел.
Я то же не смог докопаться до истины. Но есть подозрение, что ничего особого за IP адресом ELB не стоит. Иначе бы они трубили об этом, так как это весомое конкурентное преимущество. Эх, скорее бы уже времена ipv6 anycast. Больно дорог он для ipv4 получается. Кроме корневых DNS ещё не видел что бы кто-то использовал эту фишку. А ведь вот она — реально отказоустойчивая точка входа в проект.
Посматриваю на Amazon ELB и Route 53 как замену вышеописанной моей схеме. Поэтому такой интерес к данной теме. Интерес немного подрывается недавними сбоями в Amazon, которые не переживали даже очень крупные проекты. То ли их админы неправильно Amazon использовали, то ли сам Amazon в действительности, не может гарантировать отказоустойчивости даже на распределённом географически кластере.
Посматриваю на Amazon ELB и Route 53 как замену вышеописанной моей схеме. Поэтому такой интерес к данной теме. Интерес немного подрывается недавними сбоями в Amazon, которые не переживали даже очень крупные проекты. То ли их админы неправильно Amazon использовали, то ли сам Amazon в действительности, не может гарантировать отказоустойчивости даже на распределённом географически кластере.
То есть отказоустойчивость каждого конкретного ip-адреса ELB обеспечивается за счёт аналога DNS Round Robin на уровне Route 53? Правильно понимаю?
Прошу прощения, это был ответ для habrahabr.ru/post/147390/#comment_4971093. Перепутал ссылочку «ответить» с «написать комментарий».
Буду ждать второй части статьи. Очень уж интересует вариант высокодоступной системы в разных ДЦ, а, конкретно, некий сервис, где можно купить за недорого на быстром канале failover IP, направлять который можно будет куда душе угодно.
Насколько я знаю, ELB не может направлять наружу. Поправьте меня, если я ошибаюсь, но у меня получалось балансировать только сервера внутри Amazon. То есть минимальная схема использования их отказоустойчивости — Route 53 + ELB + 2xEC2 Instances. На инстансы ставится nginx или альтернативы и уже с них запросы направляются наружу.
Практика показывает, что задержки не в разы, но возрастают. Поэтому стоит хорошенько взвесить все за и против такой схемы.
Плюсом, не забываем что творилось с достаточно большими сервисами во время недавних проблем Amazon.
Практика показывает, что задержки не в разы, но возрастают. Поэтому стоит хорошенько взвесить все за и против такой схемы.
Плюсом, не забываем что творилось с достаточно большими сервисами во время недавних проблем Amazon.
Еще одним моментом отказоустойчивости, не указанный в данном переводе по понятным причинам, является использование простых и общедоступных технологий. В этот список входят все перки Amazon: ELB, Route53, EBS, SQS и прочая, прочая, прочая. Имея собственные методы скейлинга и распределения нагрузки, деплой во множественных регионах с GeoDNS и системами leader election (например Zookeeper) можно использовать только процессорные мощности клауда, причем не только Amazon.
Помните прошлогоднее падение EBS? Ну и что вы будете делать если инстанс грузится с EBS?
А что делать если ELB неожиданно перестал добавлять сервера в пул и убирать мертвые? Сам видел не раз.
Видели как ЧУЖОЙ ELB заруливает 4K req/sec трафика к вам на сервера? А я видел.
ELB вообще не гарантирует работу с вебсерверами кроме Apache2, nginx, IIS. Так что только reverse proxy, а это еще задержки и еще одно звено к поломке.
А бесконечные «connectivity issues in region»?
Все эти замечательные технологии замечательны при 2-х условиях: пока они работают без сбоев, и пока вам не надо переезжать куда-то еще. Ничто так не опасно как видимость безопасности.
На своем более чем 3-х летнем опыте построения мультирегиональных высоконагруженных и высокодоступных систем в клаудах, я бы посоветовал строить простые системы с наименьшим количеством звеньев и как можно меньшим числом проприетарных технологий.
Помните прошлогоднее падение EBS? Ну и что вы будете делать если инстанс грузится с EBS?
А что делать если ELB неожиданно перестал добавлять сервера в пул и убирать мертвые? Сам видел не раз.
Видели как ЧУЖОЙ ELB заруливает 4K req/sec трафика к вам на сервера? А я видел.
ELB вообще не гарантирует работу с вебсерверами кроме Apache2, nginx, IIS. Так что только reverse proxy, а это еще задержки и еще одно звено к поломке.
А бесконечные «connectivity issues in region»?
Все эти замечательные технологии замечательны при 2-х условиях: пока они работают без сбоев, и пока вам не надо переезжать куда-то еще. Ничто так не опасно как видимость безопасности.
На своем более чем 3-х летнем опыте построения мультирегиональных высоконагруженных и высокодоступных систем в клаудах, я бы посоветовал строить простые системы с наименьшим количеством звеньев и как можно меньшим числом проприетарных технологий.
Да, вы конечно правы, с сервисами Amazon часто случаются какие-то проблемы. Последние события, произошедшие 29-го июня сильно повлияли на один проект, к которому я имел отношение. Проблемы на Amazon совпали с нагрузочным тестированием и подбором оптимальных настроек для авто-масштабирования. Весь рабочий день был потрачен зря.
Довольно много популярных высоконагруженных приложений хосятся на Amazon.
Конечно, для критичных систем лучше иметь свои датацентры, своё железо, запасной генератор и тому подобное. С выделенными арендованными серверами, находящимися на площадках хостинг-провайдеров и самими датацентрами провайдеров тоже часто случаются проблемы.
И конечно же, чем проще система и чем там меньше звеньев тем она более надежна, особенно когда известно что стоит за конкретным звеном и как оно работает. В случае с Amazon много их сервисом это черная коробка и только на практике можно понять её поведение в разных ситуациях.
Но данные сервисы популярны у клиентов и привлекают их своей ценой и видимой простотой настройки, по сравнению с созданием инфраструктуры в реальном датацентре. Если клиент за это хочет платить, то нужно научиться создавать как можно стабильные системы на основе того, что предлагается.
Довольно много популярных высоконагруженных приложений хосятся на Amazon.
Конечно, для критичных систем лучше иметь свои датацентры, своё железо, запасной генератор и тому подобное. С выделенными арендованными серверами, находящимися на площадках хостинг-провайдеров и самими датацентрами провайдеров тоже часто случаются проблемы.
И конечно же, чем проще система и чем там меньше звеньев тем она более надежна, особенно когда известно что стоит за конкретным звеном и как оно работает. В случае с Amazon много их сервисом это черная коробка и только на практике можно понять её поведение в разных ситуациях.
Но данные сервисы популярны у клиентов и привлекают их своей ценой и видимой простотой настройки, по сравнению с созданием инфраструктуры в реальном датацентре. Если клиент за это хочет платить, то нужно научиться создавать как можно стабильные системы на основе того, что предлагается.
не поймите меня неправильно, мы живем в Амазоне, но используем его более как computational power. Это позволяет в любой момент сказать «Давай, до свидания!» или же иметь дополнительную зону в другом клауде, например RackSpace.
Я с ReckSpace тесно пока не работал, как он себя ведет в отношении стабильности работы?
Там свои прибамбасы, но в целом стабильно. Инстансы пошустрее чем у Амазона, быстрее I/O дисков, меньше шума от соседей, больше перков. У Амазона намного лучше API.
Единственное, что меня раздражает, так это политика компании. Могут позвонить и сказать: «Мы вас выключаем потому, что вы генерируете большую нагрузку. Как починим – вернем.» А все почему? Да потому, что основная масса там – обычные сайты, и дабы не гневить народ, вырубают выборочно. А причина обычно в железе, которое установили или еще что-то они там делают. С этой точки зрения Амазон намного круче для бизнеса, вот и при первом же таком заявлении, мы сказали Рэкспейсу «Bye-bye.»
Тут-то, к слову, при переезде поняли, что не стоит опираться на фичи клауда.
Единственное, что меня раздражает, так это политика компании. Могут позвонить и сказать: «Мы вас выключаем потому, что вы генерируете большую нагрузку. Как починим – вернем.» А все почему? Да потому, что основная масса там – обычные сайты, и дабы не гневить народ, вырубают выборочно. А причина обычно в железе, которое установили или еще что-то они там делают. С этой точки зрения Амазон намного круче для бизнеса, вот и при первом же таком заявлении, мы сказали Рэкспейсу «Bye-bye.»
Тут-то, к слову, при переезде поняли, что не стоит опираться на фичи клауда.
Посоветуйте, пожалуйста, что-нибудь почитать по теме. Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Варианты построения высокодоступных систем в AWS. Преодоление перебоев в работе. Часть 1