telecom №33. Работа катастрофоустойчивого хостинга
25 ноября 2015, 00:00
0
11644
24
В гостях:
Тимофей Кулин
Разработчик хостинга.
Гость 33-го выпуска Тимофей Кулин рассказывает о том, как он создал свой катастрофоустойчивый хостинг www.f1f2.ru/.
BGP для резервирования.
Ethernet-туннель для коммуникации между площадками.
Как это работает?
Скачать файл подкаста
Подписаться на podfm. Добавить RSS в подкаст-плеер.
Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.
Статья Тимофея на Хабре для ознакомления с темой: habrahabr.ru/post/248837/.
0
11644
24
Ещё выпуски
Два часа отборных ответов на отборные вопросы. Мы заканчиваем цикл подкастов про фаерволы. Нам кажется, получилось достаточно хорошо, чтобы уже никогда не возвращаться ...
25 февраля 2021
Страна мечты для многих — Германия. Однако не настолько радужная, как все про неё думают. Не фатализм, но реальность от Александра Аксёнова в ...
20 августа 2019
Продолжаем (но не заканчиваем) нашу серию про оптику. От истории развития магистральной связи через устройство оптических линий, разобравшись с компонентами сети DWDM к ...
25 ноября 2024
Человечество уже давным-давно использует водяное жидкостное охлаждение во многих сферах своей деятельности — от банального охлаждения мотора в автомобиле до снятия тепловой энергии ...
15 июня 2025
24 коментария
Как полезно слушать подкаст до конца 🙂
Оказывается машины полностью синхронизируются, ну кроме памяти.
А можете сказать чем именно вы синкаете машины?
Пробовали ли использовать Kemari или что-то подобное?
На сколько деградирует IO при вашем способе синхронизации?
Спасибо.
C Точки зрения сети все красиво и наверное не сильно дорого, но со стороны апликейшена в большинстве случаев возникнут проблемы.
Как реализовать синхронизацию баз данных, при таком переключении должен работать адекватный мастер-мастер, что само по себе проблема?
Синхронизация загруженных пользователем данных изображения, видео
Многие проекты хранят сессии в /tmp на фронтовом сервере, при переезде мы их теряем
И таких моментов очень много.
Всем такое продать не получится, клиент должен понимать на что подписывается покупая такое резервирование.
И он должен быть готов, что доработка проекта тоже будет стоить денег.
Вопросы гостю:
1. Правильно я понимаю что строится mGRE domain между всеми серверами каждого данного клиента? И он бегает прямо с сервера? И как клиенты относятся к тому, что вы собственно на сервере клиента насильно прописываете маршртизацию и если там есть шифрование — используете скорей всего немалый процент его процессора?
2. С препендами лучше поосторожней, их некоторые провы имеют привычку вырезать в транзите. Лучше или public communities, или (если блок хотя бы /23) анонс более специфических блоков (/24) с активной стороны.
3. Если блок пабликов один это значит, что один ДЦ для всех клиентов активный, а другой для всех пассивный? А что делать, если я хочу выбрать откуда давать сервис?
Вопрос ведущим — ребята, может запилите подкаст на iTunes? Очень неудобно одиночно заливать, особенно если есть техническая возможность об этом вообще не думать, а просто находить уже скачанный выпуск на телефоне.
split-brain-а нет: репликация управляется снаружи. Сейчас это полуручной режим, в разработке своя автоматика в ней тоже split-brain не будет.
А что будет в случае split-brain?
В какой-то момент гипервизоры могут потерять друг друга.
Но, мне кажется, что вероятность такого сценария несколько выше, если гипервизоры связаны через длинные сторонние каналы.
видимо да, так и придется 🙂
ну да — тут уже надо скрипт или мелкую программку писать, которая будет пинговать оба шлюза и поднимать/гасить анонсы в зависимости от доступности шлюзов
поясню подробнее.
два дц, два устройства на junos, два bgp канала, между устройствами GRE+BGP в Untrust зоне, чтобы ассиметричный трафик в итоге попал на то устройство, с которого пришло (например если пронатилось на 1 устройстве, а обратный трафик пришел на устройство 2). И вроде это все нормально работало, пока не столкнулись со странным поведением — не работает подключение по ftp + tls, или нет подключения только к одному почтовому релею из кучи. Трафик в обе стороны, в логах чисто, ничего не режется. Видим, что обратный трафик приходит ассиметрично (по идее не страшно, тысяча других ресурсов так работает), статикой исправляем ассиметрию — и все заработало. Сначала искали проблему на устройствах (на джуниперах есть крутилки, как вести себя с односторонними сессиями), потом начали работать с препендами более усиленно и искать почему есть эта небольшая ассиметрия. Ничего не помогало и пришли к тому, что видимо нужно будет полностью убирать анонсы с резервного канала, как вы и предложили. Думаем как автоматизировать.
Да, это самый простой вариант. Но нужно не потерять в отказоустойчивости. Т.е. сделать так, чтобы резервный канал сам начинал анонсировать префикс, если основной по каким то причинам упал.
Если задача полностью убрать входящий трафик на одном из каналов — почему бы тоже просто не погасить анонс?
Исходящий трафик при этом уходит как обычно.
Либо я задачу недопонял.
Понятно 🙂 у меня задача другая — обеспечить симметрию трафика в multihomed системе. Делали это через препенды, но полностью убрать трафик с отравленного канала не получилось. А оставшаяся ассиметрия иногда добавляет диких головных болей.
Спасибо, не знал про это!
Репликация делается через DRBD + собственная реализация drbd-proxy для буферизации больших объемов записи.
В теории IO не деградирует вообще: чтение всегда идёт с локальных дисков, запись на локальный диск + буфер в памяти, затем уже буфер асинхронно отправляется на резервный сервер. Это позволяет спокойно сглаживать пики записи в несколько гигабайтов-десятков гигабайтов (в зависимости от объема свободной памяти на сервере).
На практике один клиент жаловался на подвисание системы ввода-вывода при копировании файлов в несколько гигабайтов. У меня проблема не воспроизводится, а клиенту это оказалось не критично и разбираться не стали.
Kemari не пробовал — синхронизация памяти на тысячу километров убъёт производительность машины напрочь, RTT порядка 11 мс, это даже для дискового IO ощутимо (например если синхронную репликацию поставить).
С точки зрения клиента он пользуется обычным виртуальным сервером, ему не надо поднимать репликацию баз данных, файлов и т.п. репликация происходит на уровня блочных устройств, т.е. реплицируется диск виртуальной машины целиком. Т.е. и файлы и базы и настройки и установленное ПО.
Этот вариант репликации работает с любым проектом, который помещается внутрь виртуального сервера.
Это не имеет принципиального значения, т.к. в этой схеме потом анонс всё равно выключается. Это просто способ сделать переключение более плавным — для провайдеров кто учитывает препенды всё будет проходить абсолютно прозрачно без потерь пакетов.
На практике метод с препендами я не использую, т.к. переключение происходит за несколько секунд, даже tcp-сессия порваться не успеет.
Можно, конечно. Многие провы держат route-серверы на линухе. Квагга, например. Там с префиксами можно делать абсолютно все, что угодно.
2. но ведь препенды не гарантируют отключение трафика от ДЦ? на своем примере — провайдер ставит более высокий Local Preference для префиксов полученных от своих клиентов, и вот на его AS ваши препенды не играют роли.
Разве препенды можно вырезать в транзите? Если они прошли через вашего провайдера (т.е. по факту стали не в начале AS-Path, а за AS вашего провайдера), то дальше на них повлиять уже нельзя, на сколько я знаю.
RSS мне в аппликации на айфоне добавить некуда 🙁
Это как /24 не передают большинство провайдеров? Они обязаны передавать /24 и шире.
Ламер, признаюсь 🙂
Спасибо!
На айфоне в стандартном приложении Подкасты можно добавить rss.
Во вкладке Мои подкасты нужно нажать + в левом верхнем углу и выбрать «Добавить подкаст»
Вылезет окно с полем ввода куда и нужно вбить путь до rss
попробуйте overcast, в нём можно добавить подкаст через rss
1. mGRE настроен между физическими серверами хостинга, шифрование и маршрутизация там же. Ресурсы клиентских VDS в этом не участвуют. Внутри VDS клиента сеть выглядит как обычная Ethernet сеть, только MTU прописан 1400 вместо 1500 (на заголовки IPSEC, mGRE) — чтобы между ДЦ пакеты не фрагментировать принудительно.
2. Препенды как таковые не используются. Это просто вариант плавного отключения трафика от дата-центра. На практике просто выключается анонс, через 2-3 секунды весь трафик уже приходит в оставшийся ДЦ. В штатном режиме анонс сети идёт из обоих дата-центров без спец. приоритетов.
3. Блок пабликов один. Он анонсируется из обоих ДЦ одновременно, т.е. входящий трафик (в сторону VDS) идёт в тот ДЦ, который к посетителю ближе с т.з. его провайдера. Если при этом физически VDS работает в другом ДЦ — входящий трафик перенаправляется через внутреннюю сеть, на данный момент это mGRE туннели.
Исходящий трафик идёт из ДЦ где работает VDS посетителю напрямую, в любом случае без туннелей.
Т.е. вполне возможна ситуация:
Посетитель -> ДЦ1 -> ДЦ2 -> VDS (обработка запроса) -> ДЦ2 -> Посетитель.
Т.е. в случае когда трафик пришел в соседний ДЦ RTT ухудшается, но не сильно (примерно на 5мс).
Саша, в скором будущем добавим.
Но есть же RSS. Не получается просто добавить его в iTunes?
Весьма сомнительно — если препенды только некоторые вырезают, то /24 не передаёт большинство провайдеров.