Оставшийся из двух? А если балансировать как-то иначе, то, получается выдержит?
Речь о парности, которая присуща VRRP, о том, что либо сервер стоит «в запасе», либо работает, как все. В первом случае это экономически неинтересно. Во втором — при переключении нагрузка на выжившего удвоится (100% рост нагрузки). И не важно, сколько у меня серверов — они все разбиты на пары. А вот когда из 4 серверов выбывает 1, то на три оставшихся придётся +33% дополнительной нагрузки. Такую прибавку серверы, скорее всего выдержат. Это не +100%. С увеличением же количества серверов в кластере там ещё лучше получается.
1) Ну, квагга понятно, как возникла? У нас тут есть несколько человек, которые конфигуряли циску. И никого, кто мучал бы BIRD (на тот момент, когда выбирали). Вот то же самое и про ExaBGP. :) Может быть, и до него дойдёт. Правда, если реализуется несколько бешеных идей, то только BIRD нам поможет.
2) Ага! :) И ещё есть несколько трюков — сделаю статью при случае.
не обязательно full-proxy, он может не проксировать соединение, а делать dnat/snat только.
Ну, значит всё равно весь трафик через него должен идти. А у нас его очень много. Не как в mail.ru (по донесениям разведки), но порядочно.
почему не попробовали ip slb ( server load balancing)?
Хрюша больше не придёт — нет больше такой функции. Да и когда была, мне про неё гадости рассказывали. Сам попробовать не успел.
Опять же, в регионах нет у нас 6500. И не будет.
оно точно работает с помощью nat и вроде бы на скорости карточки, т.к. nat реализован в железе
Не делайте NAT на Sup2T. Я уже плавал. Больше не хочется. Дело не в производительности. Может быть, как-нить напишу…
А что мешает держать пару адресов и подхватывать по VRRP адрес упавшего?
Ничего не мешает. Вот только как ограничивать загрузку сервера не более 50%? А то если будет больше 50%, то оставшийся просто не выдержит, и сервис упадёт в полном составе.
Отлично подходят. У статических маршрутов есть возможность задать track из IP SLA, который может быть активной проверкой (даже коннектом на tcp-порт).
Не совсем. IP SLA словит только физическое пропадание сервера (сети). А это маловато будет.Нужно целяться на прикладном уровне. Если есть HTTP-проб, то да. Но как правило, такого нету. Поэтому состояние приложения проверяется на сервере, по большому количеству признаков «здоровья». А дальше — то же: сервер должен как-то сообщить роутеру о своём состоянии. Для этого берём динамический протокол маршрутизации.
Если не нужно проверять на прикладном уровне — тогда да, track.
После включения 2fa не могу залогиниться в приложении Я.Почты на iOS: ни старый пароль, ни «пароль приложения» не воспринимаются. QR-сканера в приложении нет.
Во встроенном почтовом клиенте по паролю приложения войти получается. Но хочется-то родное приложение.
Мои действия?
И второй вопрос: а можно сделать «копию» Я.Ключа на втором моём устройстве?
Я в своё время уже сталкивался с этими: «Known fixed». И приставал в поддержку. В общем, там история такая, что это следует читать так: «К этой версии есть патч, который решает данную проблему». В принципе, этот патч может дать инженер через тикет. Только поскольку это очень узкий патч, то он особо без регрессии тестируется, и бывает, что ломает что-то другое. Поэтому мне один из питерских инженеров говорил так: «Лучше апгрейд до следующей интересной версии, чем такой патч». Я с этим полностью согласен. :)
Ну вот пример из жизни: сертифицированный коммерческий ЦОД. Два луча питания, SLA, все дела. И тут однажды — бац! — один из источников питания от уважаемой фирмы ловит программную ошибку и считает своим долгом выключиться. Ну, допустим, имеет право, пока есть второй луч.
Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.
Кто-то из производителей дисков хвастался, что использует кинетическую энергию диска для генерации электроэнергии, которая используется, чтобы сбросить кэш на диск и запарковать головки.
В прошлой жизни Sybase IQ мне очень нравился для аналитики. Очень быстро и всё такое. Но вот время прошло, а они остались ровно там, где я их видел. :(
Я не говорил, что у нас устаревшее. ;) Просто памяти мало.
Да, есть такой риск. Но на практике пока что обнаружен не был. Ну, а если кто вдруг обрезает, тот пойдёт по /22 или default в Москву. А там — как апстрим решит.
нененене. Для собственной AS не нужно ничего, кроме BGP-роутера. Даже необязательно — аппаратного. :)
/27 арендовать бессмысленно, ибо по RFC какому-то префиксы длиной больше /24 положено отбрасывать.
А почему, собсно, без связности? Кто сказал, что связность не может быть через другие AS? Был вопрос, сколько AS делать, но по размышлению поняли, что одной автономки нам хватит за глаза.
Вопрос не понял :(
У нас выделенных каналов между городами нет. Даже «тонкий» канал, по которому управление идёт, для работы узла необязателен. Поэтому получается очень высокая устойчивость всей системы.
Пробросить кусок AS — можно и без anycast.
Ярослав, у меня дежа вю, что тестировали. ;)
Есть две мысли по вашем поводу:
1) чем больше параметров, тем сложнее расчет. Т.е. дольше. И больше точек отказа. А распасовщик, поди, централизованный, в Москве?
2) сетевики провайдеров не дураки, и сами следят за своими каналами. Поэтому (условно) BGP можно принять как источник информации о каналах. Поэтому любые навороты — не нужны. Ну кроме как в маркетинговых целях.
Да, anycast-балансировка страдает некоторой неопределённостью. Но это компенсируется простотой решения и обслуживания.
Речь о парности, которая присуща VRRP, о том, что либо сервер стоит «в запасе», либо работает, как все. В первом случае это экономически неинтересно. Во втором — при переключении нагрузка на выжившего удвоится (100% рост нагрузки). И не важно, сколько у меня серверов — они все разбиты на пары. А вот когда из 4 серверов выбывает 1, то на три оставшихся придётся +33% дополнительной нагрузки. Такую прибавку серверы, скорее всего выдержат. Это не +100%. С увеличением же количества серверов в кластере там ещё лучше получается.
Согласен, но не всегда и не везде.
Согласен.
В принципе, сигналить на роутер можно по-разному: хоть через CLI, хоть через XML. Что выбрать — дело вкуса.
Хотя по документации должно всё работать…
2) Ага! :) И ещё есть несколько трюков — сделаю статью при случае.
Ну, значит всё равно весь трафик через него должен идти. А у нас его очень много. Не как в mail.ru (по донесениям разведки), но порядочно.
Хрюша больше не придёт — нет больше такой функции. Да и когда была, мне про неё гадости рассказывали. Сам попробовать не успел.
Опять же, в регионах нет у нас 6500. И не будет.
Не делайте NAT на Sup2T. Я уже плавал. Больше не хочется. Дело не в производительности. Может быть, как-нить напишу…
Ничего не мешает. Вот только как ограничивать загрузку сервера не более 50%? А то если будет больше 50%, то оставшийся просто не выдержит, и сервис упадёт в полном составе.
Не совсем. IP SLA словит только физическое пропадание сервера (сети). А это маловато будет.Нужно целяться на прикладном уровне. Если есть HTTP-проб, то да. Но как правило, такого нету. Поэтому состояние приложения проверяется на сервере, по большому количеству признаков «здоровья». А дальше — то же: сервер должен как-то сообщить роутеру о своём состоянии. Для этого берём динамический протокол маршрутизации.
Если не нужно проверять на прикладном уровне — тогда да, track.
Во встроенном почтовом клиенте по паролю приложения войти получается. Но хочется-то родное приложение.
Мои действия?
И второй вопрос: а можно сделать «копию» Я.Ключа на втором моём устройстве?
Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.
Да, есть такой риск. Но на практике пока что обнаружен не был. Ну, а если кто вдруг обрезает, тот пойдёт по /22 или default в Москву. А там — как апстрим решит.
Про автономки — в общем-то, распространённое заблуждение.
/27 арендовать бессмысленно, ибо по RFC какому-то префиксы длиной больше /24 положено отбрасывать.
А почему, собсно, без связности? Кто сказал, что связность не может быть через другие AS? Был вопрос, сколько AS делать, но по размышлению поняли, что одной автономки нам хватит за глаза.
У нас выделенных каналов между городами нет. Даже «тонкий» канал, по которому управление идёт, для работы узла необязателен. Поэтому получается очень высокая устойчивость всей системы.
Пробросить кусок AS — можно и без anycast.
Есть две мысли по вашем поводу:
1) чем больше параметров, тем сложнее расчет. Т.е. дольше. И больше точек отказа. А распасовщик, поди, централизованный, в Москве?
2) сетевики провайдеров не дураки, и сами следят за своими каналами. Поэтому (условно) BGP можно принять как источник информации о каналах. Поэтому любые навороты — не нужны. Ну кроме как в маркетинговых целях.
Да, anycast-балансировка страдает некоторой неопределённостью. Но это компенсируется простотой решения и обслуживания.