telecom №33. Работа катастрофоустойчивого хостинга
25 ноября 2015, 00:00
0
9619
24
В гостях:
Тимофей Кулин
Разработчик хостинга.
Гость 33-го выпуска Тимофей Кулин рассказывает о том, как он создал свой катастрофоустойчивый хостинг www.f1f2.ru/.
BGP для резервирования.
Ethernet-туннель для коммуникации между площадками.
Как это работает?
Скачать файл подкаста
Подписаться на podfm. Добавить RSS в подкаст-плеер.
Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.
Статья Тимофея на Хабре для ознакомления с темой: habrahabr.ru/post/248837/.
0
9619
24
Ещё выпуски
Продолжаем тему Software Defined Networking. По словам нашего гостя SDN — это наше настоящее. Сетевым инженерам надо меняться, хотя, безусловно есть шанс дотянуть ...
25 декабря 2017
В 7-м выпуске у нас двойной дебют: новая девушка подкаста — Наташа — и гость выпуска — Тимофей Слуев — инженер TAC комании ...
24 сентября 2013
Продолжаем на практике доказывать, что самые лучшие интервью пишутся спонтанно. В один из предновогодних вечеров, удачно зайдя в офис Комфортел, Саша Мамонт разговорился ...
15 января 2020
Евгения Голева. Lamoda. Как делать из айтишников крутых докладчиков и “амбассадоров бренда”, зачем это нужно компании и почему Lamoda — это не просто ...
31 мая 2019
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 не передаёт большинство провайдеров.