Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

А кто как зеркалирует ресурсы?

Привет.

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

Решения, которые рассматривались:
— 2 точки с приложением, проксирование запросов на одну из машин, пока она работает. Если упала — меняем на айпи другой машины. Минусы: третья машина — уязвимая точка.
— DNS смена IPшников. Минусы: долгое переключение из-за кеширования DNS
— плавающий IP. Минусы: не сделать в рамках двух ДЦ.

Коллеги, нужны ваши советы и варианты решений.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почитайте вот это:
www.amazon.com/...34&linkCode=as2

Если покажется мало, то еще парочка:

www.amazon.com/...LE&linkCode=as2
www.amazon.com/...Y0&linkCode=as2

P.S. Некоторые советы, типа RR DNS ужасны, вроде уже 2014 год, а не 2004:)

Тем не менее это используется тем же гуглом и яндексом.

Если уж вы вспомнили про Яндекс, то вот их сотрудники рассказывают. Раз — tech.yandex.ru/...2012/talks/432

Два — tech.yandex.ru/...2012/talks/379

За линки спасибо, но они никак не отменяют того факта, что RR DNS они используют и похоже отказываться не собираются.

Раз — tech.yandex.ru/...2012/talks/432
Все не смотрел, но после того как в презентации появился дополнительный балансер ничего не сказано каким образом мы попадаем на конкретный балансер в случае выхода из строя одного из них. Дальше уже про БД и как по мне не лучшее описание идеи (про БД мне вот статья понравилась habrahabr.ru/...x/blog/146490/
Два — tech.yandex.ru/...2012/talks/379
тут еще надо будет вникнуть.

Я бы не стал рассуждать в про RR в Яндексе, в отрыве от всей картины. Добавлю еще линк, на тот же Route53 docs.aws.amazon.com/...s-failover.html

Так чего рассуждать делаем dig ya.ru и получаем список IP. Дальше уже вероятно есть дополнительные способы обеспечения надежности, но сам факт использования думаю отрицать нельзя.

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

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

— DNS смена IPшников. Минусы: долгое переключение из-за кеширования DNS
Не совсем понимаю вы про, несколько IP на один DNS. Если да то в чем беда с кешированием ? Опишите ситуацию если можно.

Имелось в виду round-robin и исключение IP в случае падения машины.

имхо разные ДЦ — это скорее средство для уменшения latency, а не для повышения доступности.
Для повышения доступности надо делать масштабируемую архитектуру внутри ДЦ — в любой момент должна быть возможность добавить сервера приложений, базы данных, мемкеши, ... (не знаю что там у вас ещё) и обязательно — мониторинг для всего этого
Распределять трафик — да для начала можно одинм nginx-ом или haproxy. Если будет не хватать — смотреть на железяки для load balancing-а

Возможно. Но украинские ДЦ, как показывает практика, зачастую имеют 1 канал и не имеют защиты от DDoS.

имхо разные ДЦ — это скорее средство для уменшения latency, а не для повышения доступности.
Вот из-за таких как ты с падением зоны амазона пол интернета ложится.

Проще сделать чтобы сервера не падали. То есть первым и зачастую единственным способом является повышение стабильности сревреров.
Одно дело когда они просто не справляются с нагрузкой. И совсем другое — когда там говнокод, и тогда увеличение числа исполнителей говнокода не решает проблему, а рождает ещё одну.

По наргузке наиболее правильно — функциональное деление, либо ествественная параллелизация (одни юзеры туда, другие сюда, видео вообще к чёрту на кулички). Задача именно в том, чтобы код требующий много взаимодействий оставался в рамках одной машины. Либо стоящей совсем рядом, лучше в той же стойке. А код/данные между которым серверных зависимостей мало — егои разносят. Таким образом данные тоже разносят, а не зеркалируют. Тогда и серверам требуется меньше ресурсов, и вероятность падения каждого ниже, и проблемы искать проще. И главное — отключение одного не влияет на остальной функционал.

Например, ВКонтакте перестало работать видео на полчаса. Да всем будет пофиг поначалу! А вот положили бы его на один сервер с авторизацией — и уже геморой.

Так что меньше теории надёжности, подойти с точки зрения теории ограничений. Другими словами, ищи где точно узкое место. А не просто «сервер ниработаит».

Я точно скажу, что плодить сервера — надёжности против естественных источников не добавляет. Разве что против DDoS и прочих атак. Но тогда решением становится одна машинка, которая будет следить за доступностью, и иметь какой-то алгоритм локализации проблем. Например, Китай обслуживать по одному порту, а США по другому. Железо как раз является самым надёжным узлом, а потому его нет смысла параллелить ради надёжности. Равно как и география — ради надёжности весь функционал должен быть в одном месте, а в резервное — только бэкап.

Холодный резерв рулит для географического разнесения. А горячий — должен иметь минимальные задержки, иначе он никогда не даст того что от него ждёшь.

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

[IMHO] А вот нечего патчи сразу в продакшн накатывать. Для дисков RAID а сетевые не горят в адекватных ДЦ с охлаждением, заземлением, грозозащитой. (Шанс их выхода из строя не стоит чтоб об этом думать)

Ну вот это и решает резерв, расположенный в том же дата-центре. Чем горячий резерв ближе — тем лучше. Мало того, на нём ты можешь расположить ресурсы, падение которых не критично. В случае падения основного — ресурсы гасишь (или снижаешь приоритеты задачам) и отдаёшь под резерв. Так ещё и в деньгах экономишь.

Трафик еще ладно, данные реплицировать как — уже придумали? Или там ридонли?

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

— плавающий IP. Минусы: не сделать в рамках двух ДЦ.
Взрослые дяди как раз решают такие проблемы с помощью плавающего АйПи. Если один ДЦ упал, то пакеты на АйПи начинают раутится в другой ДЦ.
Если у тебя маленький уютненький бложек, то лучше забить на cross-dc failover, падение датацентров не настолько частая ситуация что бы усложнять инфраструктуру из-за этого.

наши сервисы/сайты для того чтобы не уходили в дун при высоких нагрузках- находятся за лоад балансером. Физически- это несколько серверов в одном датацентре. Все они стоят за сервером балансировки нагрузок. Наружу торчит единый ip

А что из себя представляет балансировщик? софт или железо?

Я не знаю- это услуга хостера.

Как правило это железяка. Есть софтовые, но у них возможности скромнее.

Если делать в рамках одного ДЦ, делать либо через nginx или round robin DNS. При первом варианте допускается использование общего хранилища для сессий, кеша, всякой инфы которую нужно быстро отдать и общего сервера БД. Балансировать нагрузку будет nginx.
Во втором варианте все тоже самое только будет распределяться нагрузка через механизм round robin используя DNS (выставив айпишники бекендов наружу) без nginx ну или какой вы там веб сервер используете.
Если вариант с двумя ДЦ, то тут можно сделать либо как с round robin выставив айпишники наружу + ко всему прийдется делать master-master репликацию БД и хранилища сессий, кеша... и т.д. Так же можно сделать через вариант с двумя nginx, за ними бекенды. Выставив aйпишники nginx наружу, и опять таки репликация master-master и round robin через DNS. При этом получаете сразу из коробки — вариант с двумя ДЦ, балансировку при между бекендами на каждом из ДЦ, отказоустойчивость. Она отработает ровно настолько насколько правильно настроены все компоненты данных схем.

round robin через DNS
И как именно это спасает от падения ДЦ? У юзера же АйПи закешируется, и пока кеш не выгорит, не сможет он поиграть в танчики.

Или еще лучше — каждый второй клик пойдет в никуда.

А вы пробовали как это работает ? ;)

RR DNS? Раунд робином! (Кэп)
Между ЦОД бигипой кошерно же. Внутри пара балансеров. Но то энтерпрайз.
Для себя любимого, если репликация данных не проблема, nginx/pacemaker ок вроде, хотя давно уже не копал, мог отстать от жизни.
.
Колитесь уже — как у вас? )

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

Я уже написал выше как это делают взрослые дяди. Если один датацентр упал, то делается рероутинг айпишника на другой датацентр. Анонс занимает меньше секунды.

попробуйте еще разместить ваш вопрос на opennet.ru , это может ускорить решение Вашей проблемы

Подписаться на комментарии