Комментарии 36
Не, пусть мрут когда хотят. Абы N+1/N+2 сохранялись... (и да, обидно, что добавлять один Самый Супер Сильный в группу не смысла, он-то и есть тот самый +1)
Задача вообще непонятна. Обычно ж стараются, чтобы всё разом не умирало, а не наоборот.
Тут проблема была в том, что ресурсы были несбалансированы между собой. Есть мощные и дохлые узлы. Если просто разделить трафик в равных пропорциях, часть узлов уже ляжет под нагрузкой, а часть будет нагружена наполовину от своих возможностей.
Но вот задача правильной балансировки была трудновыполнима из-за того, что не было нормальной модели и нормализованного мониторинга нагрузки.
@aamonster совершенно верно акцентирует внимание на несколько чудовищную формулировку задачи.
К нам обратился заказчик ... у него серверы падали не одновременно
Проблемы появились тогда, когда встал вопрос с георезервированием и масштабированием при росте нагрузок. Серверы внутри одной группы резервирования умирали не синхронно
А вот цели проекта сформулированы просто великолепно
Project Goals
To develop a methodology for predicting the dynamics of reserve capacity and the need for storage expansion.
Простите за такой кликбейт в формулировках. По сути, было необходимо обеспечить равномерность нагрузки на серверы с очень разными характеристиками, чтобы полностью утилизировать мощность.
Если часть уже откажет, а часть останется функциональными, то это не спасет в этой архитектуре. Вся группа уже будет нерабочей. Но да, в условиях идеальной балансировки они действительно синхронно падают при DDoS. Конечно, не в этом была основная цель, просто забавное наблюдение и критерий хорошей балансировки.
Ну так старый добрый кликбейт же.
Я собственно из-за заголовка и зашел, стало интересно, зачем может понадобиться синхронно ронять все сервера.
Я даже догадался, в чём была реальная проблема (глупо переплачивать за мощные сервера, которые работают с такой же нагрузкой, как хилые), но прозвучало крайне странно :-)
Напрашивается вопрос, а нельзя сделать не пропорциональную нагрузку с перераспределением при падении узлов? Конечно, задача не очень простая потому что нужно проводить целое исследование для поиска оптимального алгоритма. Но это реально. Потому что…задача действительно странная. Обрубить стек серверов из-за отказа одного, но ведь если вы убиваете стек серверов в CDN трафик волшебным образом не пропадает, значит все это успешно ударит по другому стеку серверов который работает.
Очень даже молодцы. Не стали с умным видом рассказывать, мол у вас тут все не правильно, давайте все строить заново, а сначала разобрались с текущей ситуацией, помогли заказчику, а уж потом потихоньку можно будет привести все в божеский вид. Я думаю заказчик должен быть очень благодарен.
Интересно, хоть каналы-то были безлимитные по объему в месяц? Или до некоторой величины оплачено, а далее погигабайтно?
Н могу еще понять: если сервер выведен/умер, а его ip все еще запрашивается клиентами, то не так это и удобно. Тут уже клиентское ПО должно тестировать серверы и выбирать живые, разве не так решать проще всего?
Там зоопарк) одновременно были варианты:
Канал безлимитный по общему трафику, но ограничен по ширине. Обычно это узлы по 1-2.5 гигабита.
Канал органичен по ширине, в стоимость входит пакет трафика, потом за дополнительные деньги.
Канал без формального лимита по ширине канала, пакета трафика нет, тарифицируются гигабайты.
Финансовую оптимизацию мы позднее делали, там вообще весело было. До полноценного мониторинга было сложно посчитать вообще что и сколько стоит.
Насчёт того, что мертвый сервер не должен отдаваться клиентам - я согласен. Но там были особенности, которые не давали это сделать.
Всё понимаю, но оптимизировать зоопарк, получив в итоге другой зоопарк, обычно чревато:
скорее всего, заказчик имеет привычку "экономить не экономя" (делать телодвижения по экономии затрат, не учитывая всех подробностей, в т.ч. трудозатрат и невозможности хорошо управлять серверами и трафиком) - получается, оптимизация учитывает не все метрики (учитывает месячный чек, но не учитывает геморой и легкость управления). А с пере-экономичным, заклиненным на суммах, заказчиком возникают доп. риски.
как ни крути, оптимизация будет "по состоянию на сегодня", автоматизировать или алгоритмизировать её на будущее будет сложно.
Получается, что сделать свой CDN вместо более дорогого готового - это, возможно, (финансовое) благо, а вот привести его в порядок - тяжелое и неблагодарное (см. выше) дело.
Но всё же, неужели прибыли от проекта заказчику не хватило, чтобы привести серверый парк к одному (или нескольким, но - единичным) стандарту?
Там была скорее проблема быстрого хаотичного роста "потому что так сложилось". И на самом деле, не все так плохо. Это был первый этап, который закрывал текущую проблему и давал время на полноценный рефакторинг.
Несколько забегая вперед - оптимизировали, унифицировали и сумели убрать большую часть серверов при итоговом росте надежности. Так что это скорее история о том, что не всегда нужно брать и выбрасывать сразу.
С финансовой точки зрения, вопрос не в том, чтобы прибыли хватило, а в многократной разнице совокупной стоимости владения. Конкретные цифры я озвучить не могу, но сторонний CDN может быть существенно дороже хорошо оптимизированных bare-metal решений. Конечно, все это зависит от конкретного случая. В первую очередь свои сервера намного выгоднее при равномерной средней нагруженности.
Уже десять лет существует технология webtorrent в т.ч. для стриминга, но видеоконтент продолжают отдавать по старинке.
Или у p2p технологий есть какая то неразрешимая фатальная проблема, почему ее не внедряют везде?
Это то что с WebRTC?
Я когда-то тестировал один сервис.
Он не особо снимал нагрузку с серверов.
Все за NATом сидят, а если у обоих пиров NAT, то нужен еще сервер, который их соединит и будет через себя гнать трафик, проще напрямую отдать.
Возможно, IPv6 в итоге изменит ситуацию. Мы видели большие объемы трафика через него а ЮВА.
NAT-ы бывают разные, типовой nat который по умолчанию у всех у кого роутер с wifi и динамическим/статическим ip, пролезает с помощью stun сервера (когда для начала разговора нужен третий, но весь трафик пойдет напрямую между пирами, даже если они оба за nat), вот с мобильными сложнее, там провайдеры могут нагородить вложенные nat.
Про типовой нат. Я даже проверил сейчас - у меня провайдер выдает мне серый адрес, он назначается роутеру и роутер внутри квартиры раздает клиентам (опять же через nat) второй слой серых адресов. Т.е. типовая конфигурация - двойной nat. Это крупнейший провайдер в Москве. И так уже лет 10. И думаю так будет у любого более-менее крупного провайдера, т.к. с нынешними ценами на ipv4 первое что приходит в голову для оптимизации расходов - это загнать всех клиентов за nat.
TURN и ко давно эту проблему решает достаточно надёжно.
Насколько я понимаю, через TURN весь трафик и ходит при этом, а если трафик от клиента к клиенту ходит через ваш-же сервер/канал, то зачем огород городить?
Нет, TURN нужен только чтобы дырявить NAT и сводить клиентов друг с другом (сообщая номера портов и т.п.). Трафик ходит напрямую.
Это STUN. А про TURN вот что пишут на webrtc org: For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). The common way to solve this is by using a TURN server. The term stands for Traversal Using Relays around NAT, and it is a protocol for relaying network traffic.
Ну и выше человек написал, что пробовал он, но нагрузка уменьшается незначительно, большинство клиентов не могут друг до друга достучаться. Для экономии адресов провайдеры сейчас городят nat на nat-е и nat-ом погоняет.
Итак, в очередной раз сферы развлекательного видеостриминга, пуст немного, но подстегнули прогресс.
У них часто интересные задачи , требующие необычных решений.
Интересный способ сказать, что там всегда всё через одно место...
Всякое бывает. Часто это довольно старые проекты, которые внезапно обнаружили, что им нужно обслуживать тяжёлые нагрузки, и сделали как смогли. Да, многие решения могут выглядеть несколько необычно. Но они работают и приносят доход.
Поэтому, приходится все аккуратно и последовательно все оптимизировать.
В похожей ситуации использовали такой подход: m3u динамический, плейлисты отдаются высокопроизводительным бэкендом. Там высокий rps, но нет io, и сами плейлисты мелкие, поэтому bandwidth не занят у серверов.
При генерации плейлиста учитывалась нагрузка на серверы, отдающие непосредственно видеочанки. Серверы выводились из балансировки при недоступности, или когда полоса была на пределе. А ещё автоматом подкидывалась раздача через cdn, когда полоса всех серверов группы была близка к пределу
Извините, что не совсем по теме вашего кейса
У меня давно была открыта вкладка вашего сайта (на ru) с вакансиями девопсов, а теперь сайт полностью на en и ссылка на вакансии пропала. Можно её как то вернуть? Спасибо.
Мы хотим, чтобы серверы падали одновременно