Вхід і реєстрація
Розробка · 14 травня 2014, 17:07 697
Alex Danilov, Senior software engineer

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

Привет.

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

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

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: архітектура, хостинг
👍ПодобаєтьсяСподобалось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
Anton Koshevyi Infra в MacPaw 22.05.2014 11:51

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

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

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

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

Відповісти
Підтримати
Nikita Podgorbunskyi Software Engineer 22.05.2014 14:02

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

Відповісти
Підтримати
Anton Koshevyi
Anton Koshevyi Infra в MacPaw 22.05.2014 14:38

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

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

Відповісти
Підтримати
Nikita Podgorbunskyi
Nikita Podgorbunskyi Software Engineer 22.05.2014 15:03

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

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

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

Відповісти
Підтримати
Nikita Podgorbunskyi
Nikita Podgorbunskyi Software Engineer 23.05.2014 11:22

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

Відповісти
Підтримати
Anton Koshevyi
Anton Koshevyi Infra в MacPaw 23.05.2014 11:50

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

Відповісти
Підтримати
Nikita Podgorbunskyi
Nikita Podgorbunskyi Software Engineer 23.05.2014 12:34

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

Відповісти
Підтримати
Anton Koshevyi
Nikita Podgorbunskyi Software Engineer 15.05.2014 13:12
— DNS смена IPшников. Минусы: долгое переключение из-за кеширования DNS
Не совсем понимаю вы про, несколько IP на один DNS. Если да то в чем беда с кешированием ? Опишите ситуацию если можно.
Відповісти
Підтримати
Alex Danilov Senior software engineer 15.05.2014 13:17

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

Відповісти
Підтримати
Nikita Podgorbunskyi
Макс Матюхин программист в Badoo 15.05.2014 11:28

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

Відповісти
Підтримати
Alex Danilov Senior software engineer 15.05.2014 13:18

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

Відповісти
Підтримати
Макс Матюхин
reality_hacker 16.05.2014 00:17
имхо разные ДЦ — это скорее средство для уменшения latency, а не для повышения доступности.
Вот из-за таких как ты с падением зоны амазона пол интернета ложится.
Відповісти
Підтримати
Макс Матюхин
Олексій Пєніє 15.05.2014 07:33

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

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

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

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

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

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

Відповісти
Підтримати
Alex Danilov Senior software engineer 15.05.2014 13:19

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

Відповісти
Підтримати
Олексій Пєніє
Oleh 15.05.2014 20:05

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

Відповісти
Підтримати
Alex Danilov
Олексій Пєніє 16.05.2014 12:29

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

Відповісти
Підтримати
Alex Danilov
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 15.05.2014 00:59

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

Відповісти
Підтримати
Mobile 15.05.2014 00:13

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

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

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

Відповісти
Підтримати
Alex Danilov Senior software engineer 14.05.2014 23:50

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

Відповісти
Підтримати
Lyova Zi
Lyova Zi 15.05.2014 21:31

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

Відповісти
Підтримати
Alex Danilov
Dmitry Goncharenko SDE в Amazon 15.05.2014 22:01

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

Відповісти
Підтримати
Alex Danilov
Олександр Книш DevOps Team Lead 20.05.2014 22:04

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

Відповісти
Підтримати
Alex Danilov
reality_hacker 21.05.2014 03:54
round robin через DNS
И как именно это спасает от падения ДЦ? У юзера же АйПи закешируется, и пока кеш не выгорит, не сможет он поиграть в танчики.
Відповісти
Підтримати
Олександр Книш
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 21.05.2014 12:42

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

Відповісти
Підтримати
reality_hacker
Олександр Книш DevOps Team Lead 22.05.2014 09:35

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

Відповісти
Підтримати
Tim Tretyak
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 22.05.2014 13:07

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

Відповісти
Підтримати
Олександр Книш
Олександр Книш DevOps Team Lead 22.05.2014 09:36

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

Відповісти
Підтримати
reality_hacker
reality_hacker 22.05.2014 09:38

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

Відповісти
Підтримати
Олександр Книш
Iryna Volkodav engineer в e-commerce startup 14.05.2014 22:20

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.