return

telecom №33. Работа катастрофоустойчивого хостинга

25 ноября 2015, 00:00
like 0 views 9552 message 24

24 коментария

  • Артем Феофанов

    Как полезно слушать подкаст до конца 🙂
    Оказывается машины полностью синхронизируются, ну кроме памяти.
    А можете сказать чем именно вы синкаете машины?
    Пробовали ли использовать Kemari или что-то подобное?
    На сколько деградирует IO при вашем способе синхронизации?

    Спасибо.

    8 декабря 2015, 14:02
  • Артем Феофанов

    C Точки зрения сети все красиво и наверное не сильно дорого, но со стороны апликейшена в большинстве случаев возникнут проблемы.
    Как реализовать синхронизацию баз данных, при таком переключении должен работать адекватный мастер-мастер, что само по себе проблема?
    Синхронизация загруженных пользователем данных изображения, видео
    Многие проекты хранят сессии в /tmp на фронтовом сервере, при переезде мы их теряем
    И таких моментов очень много.
    Всем такое продать не получится, клиент должен понимать на что подписывается покупая такое резервирование.
    И он должен быть готов, что доработка проекта тоже будет стоить денег.

    4 декабря 2015, 10:49
  • Александр Клиппер

    Вопросы гостю:
    1. Правильно я понимаю что строится mGRE domain между всеми серверами каждого данного клиента? И он бегает прямо с сервера? И как клиенты относятся к тому, что вы собственно на сервере клиента насильно прописываете маршртизацию и если там есть шифрование — используете скорей всего немалый процент его процессора?
    2. С препендами лучше поосторожней, их некоторые провы имеют привычку вырезать в транзите. Лучше или public communities, или (если блок хотя бы /23) анонс более специфических блоков (/24) с активной стороны.
    3. Если блок пабликов один это значит, что один ДЦ для всех клиентов активный, а другой для всех пассивный? А что делать, если я хочу выбрать откуда давать сервис?

    Вопрос ведущим — ребята, может запилите подкаст на iTunes? Очень неудобно одиночно заливать, особенно если есть техническая возможность об этом вообще не думать, а просто находить уже скачанный выпуск на телефоне.

    26 ноября 2015, 00:39
  • split-brain-а нет: репликация управляется снаружи. Сейчас это полуручной режим, в разработке своя автоматика в ней тоже split-brain не будет.

    24 декабря 2015, 01:06
  • А что будет в случае split-brain?
    В какой-то момент гипервизоры могут потерять друг друга.
    Но, мне кажется, что вероятность такого сценария несколько выше, если гипервизоры связаны через длинные сторонние каналы.

    23 декабря 2015, 11:51
  • видимо да, так и придется 🙂

    23 декабря 2015, 11:50
  • ну да — тут уже надо скрипт или мелкую программку писать, которая будет пинговать оба шлюза и поднимать/гасить анонсы в зависимости от доступности шлюзов

    23 декабря 2015, 11:49
  • поясню подробнее.
    два дц, два устройства на junos, два bgp канала, между устройствами GRE+BGP в Untrust зоне, чтобы ассиметричный трафик в итоге попал на то устройство, с которого пришло (например если пронатилось на 1 устройстве, а обратный трафик пришел на устройство 2). И вроде это все нормально работало, пока не столкнулись со странным поведением — не работает подключение по ftp + tls, или нет подключения только к одному почтовому релею из кучи. Трафик в обе стороны, в логах чисто, ничего не режется. Видим, что обратный трафик приходит ассиметрично (по идее не страшно, тысяча других ресурсов так работает), статикой исправляем ассиметрию — и все заработало. Сначала искали проблему на устройствах (на джуниперах есть крутилки, как вести себя с односторонними сессиями), потом начали работать с препендами более усиленно и искать почему есть эта небольшая ассиметрия. Ничего не помогало и пришли к тому, что видимо нужно будет полностью убирать анонсы с резервного канала, как вы и предложили. Думаем как автоматизировать.

    23 декабря 2015, 11:49
  • Да, это самый простой вариант. Но нужно не потерять в отказоустойчивости. Т.е. сделать так, чтобы резервный канал сам начинал анонсировать префикс, если основной по каким то причинам упал.

    23 декабря 2015, 11:38
  • Если задача полностью убрать входящий трафик на одном из каналов — почему бы тоже просто не погасить анонс?
    Исходящий трафик при этом уходит как обычно.

    Либо я задачу недопонял.

    23 декабря 2015, 11:08
  • Понятно 🙂 у меня задача другая — обеспечить симметрию трафика в multihomed системе. Делали это через препенды, но полностью убрать трафик с отравленного канала не получилось. А оставшаяся ассиметрия иногда добавляет диких головных болей.

    23 декабря 2015, 11:06
  • Спасибо, не знал про это!

    23 декабря 2015, 10:53
  • Репликация делается через DRBD + собственная реализация drbd-proxy для буферизации больших объемов записи.

    В теории IO не деградирует вообще: чтение всегда идёт с локальных дисков, запись на локальный диск + буфер в памяти, затем уже буфер асинхронно отправляется на резервный сервер. Это позволяет спокойно сглаживать пики записи в несколько гигабайтов-десятков гигабайтов (в зависимости от объема свободной памяти на сервере).

    На практике один клиент жаловался на подвисание системы ввода-вывода при копировании файлов в несколько гигабайтов. У меня проблема не воспроизводится, а клиенту это оказалось не критично и разбираться не стали.

    Kemari не пробовал — синхронизация памяти на тысячу километров убъёт производительность машины напрочь, RTT порядка 11 мс, это даже для дискового IO ощутимо (например если синхронную репликацию поставить).

    23 декабря 2015, 00:56
  • С точки зрения клиента он пользуется обычным виртуальным сервером, ему не надо поднимать репликацию баз данных, файлов и т.п. репликация происходит на уровня блочных устройств, т.е. реплицируется диск виртуальной машины целиком. Т.е. и файлы и базы и настройки и установленное ПО.

    Этот вариант репликации работает с любым проектом, который помещается внутрь виртуального сервера.

    23 декабря 2015, 00:47
  • Это не имеет принципиального значения, т.к. в этой схеме потом анонс всё равно выключается. Это просто способ сделать переключение более плавным — для провайдеров кто учитывает препенды всё будет проходить абсолютно прозрачно без потерь пакетов.

    На практике метод с препендами я не использую, т.к. переключение происходит за несколько секунд, даже tcp-сессия порваться не успеет.

    23 декабря 2015, 00:45
  • Александр Клиппер

    Можно, конечно. Многие провы держат route-серверы на линухе. Квагга, например. Там с префиксами можно делать абсолютно все, что угодно.

    22 декабря 2015, 17:47
  • 2. но ведь препенды не гарантируют отключение трафика от ДЦ? на своем примере — провайдер ставит более высокий Local Preference для префиксов полученных от своих клиентов, и вот на его AS ваши препенды не играют роли.

    22 декабря 2015, 17:45
  • Разве препенды можно вырезать в транзите? Если они прошли через вашего провайдера (т.е. по факту стали не в начале AS-Path, а за AS вашего провайдера), то дальше на них повлиять уже нельзя, на сколько я знаю.

    22 декабря 2015, 17:15
  • Александр Клиппер

    RSS мне в аппликации на айфоне добавить некуда 🙁

    Это как /24 не передают большинство провайдеров? Они обязаны передавать /24 и шире.

    26 ноября 2015, 10:08
  • Александр Клиппер

    Ламер, признаюсь 🙂
    Спасибо!

    9 декабря 2015, 11:06
  • Артем Феофанов

    На айфоне в стандартном приложении Подкасты можно добавить rss.
    Во вкладке Мои подкасты нужно нажать + в левом верхнем углу и выбрать «Добавить подкаст»
    Вылезет окно с полем ввода куда и нужно вбить путь до rss

    8 декабря 2015, 14:07
  • попробуйте overcast, в нём можно добавить подкаст через rss

    4 декабря 2015, 11:37
  • 1. mGRE настроен между физическими серверами хостинга, шифрование и маршрутизация там же. Ресурсы клиентских VDS в этом не участвуют. Внутри VDS клиента сеть выглядит как обычная Ethernet сеть, только MTU прописан 1400 вместо 1500 (на заголовки IPSEC, mGRE) — чтобы между ДЦ пакеты не фрагментировать принудительно.
    2. Препенды как таковые не используются. Это просто вариант плавного отключения трафика от дата-центра. На практике просто выключается анонс, через 2-3 секунды весь трафик уже приходит в оставшийся ДЦ. В штатном режиме анонс сети идёт из обоих дата-центров без спец. приоритетов.
    3. Блок пабликов один. Он анонсируется из обоих ДЦ одновременно, т.е. входящий трафик (в сторону VDS) идёт в тот ДЦ, который к посетителю ближе с т.з. его провайдера. Если при этом физически VDS работает в другом ДЦ — входящий трафик перенаправляется через внутреннюю сеть, на данный момент это mGRE туннели.
    Исходящий трафик идёт из ДЦ где работает VDS посетителю напрямую, в любом случае без туннелей.

    Т.е. вполне возможна ситуация:
    Посетитель -> ДЦ1 -> ДЦ2 -> VDS (обработка запроса) -> ДЦ2 -> Посетитель.

    Т.е. в случае когда трафик пришел в соседний ДЦ RTT ухудшается, но не сильно (примерно на 5мс).

    26 ноября 2015, 17:27
  • Саша, в скором будущем добавим.
    Но есть же RSS. Не получается просто добавить его в iTunes?

    2. С препендами лучше поосторожней, их некоторые провы имеют привычку вырезать в транзите. Лучше или public communities, или (если блок хотя бы /23) анонс более специфических блоков (/24) с активной стороны.

    Весьма сомнительно — если препенды только некоторые вырезают, то /24 не передаёт большинство провайдеров.

    26 ноября 2015, 04:34
Ещё выпуски
telecom №45. Data Center Interconnection (DCI)
В продолжение 12-й части СДСМ Александр Клиппер, гость 23-го выпуска рассказывает про Data Center Interconnection (DCI): TRILLVXLANOTVEVPN/VPLS Скачать файл подкаста
like 0 12408 17
telecom №94. Фаерволы, файрволы, фаэрволы и файеэоывалорволы. Часть ...
Кто бы мог подумать, что самые громкие прения будут не вокруг «NAT как средство безопасности», а вокруг написания слова «Firewall» на русском. Мы ...
like 2 2223 0
По'уехавшие №24. Вьетнам. Денис Богатырёв
​Мы так долго этого ждали и вот Ура! Азия! Снова. Страна, в которой побывал каждый десятый россиянин, и о переезде в которую задумывается ...
like 1 1085 0
LTE №0. Как "оптимизировать" BGP. Артём Гавриченков
Мы открываем новый формат — интервью с экспертом или LTE (Long Talk to Expert). Это будут интервью с известными и уважаемыми людьми в ...
like 0 2516 0
00:00 00:00