В разных регионах по-разному. Где-то побольше, где-то поменьше. В целом, у нас такая информация считается закрытой, поэтому скажу так: у нас в регионах к узлам подключены десятки гигабит (на один узел, чтобы не было разночтений).
К ACE за все время использования ни единой претензии не было.
У меня к нему сейчас только одна претензия — новым клиентам больше не продаётся. В общем, убила его циска. Может, там и была нехватка производительности, ещё какие-то проблемы — этого я уже никогда не узнаю.
Я правильно понимаю, что сервер балансировщик L7 не состоянии перемолоть больше чем 10gbps?
1) на момент принятия решения я не имел данных об аппаратных балансировщиках, тянущих больше 10Гбит/с. Может, сейчас уже есть. Но ценник всё равно будет космический.
2) предположим, что сервер с Haproxy/nginx может тянуть 20Гбит. Ладно! Гуляем на все 40, как Нетфликс!!! Их всё равно надо купить много штук, поставить в стойку, как-то зарезервировать, обеспечить сетью (портами, полосой) на все эти гигабиты. И сделать это на каждом нашем узле — не только в Москве. Много. Дорого. Хреново в обслуживании (просто за счёт количества).
Да, если есть конкретные требования к server affinity, как у JDima, то да, там вариантов нет. Но если задача на прикладном уровне позволяет обойтись без привязки клиента к серверу (а я бы для всех веб-проектов рекомендовал делать без привязки), то нет смысла в «тяжелом» L7-балансировщике.
Да, мои соболезнования!
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.
Оставшийся из двух? А если балансировать как-то иначе, то, получается выдержит?
Речь о парности, которая присуща 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 мне очень нравился для аналитики. Очень быстро и всё такое. Но вот время прошло, а они остались ровно там, где я их видел. :(
У меня к нему сейчас только одна претензия — новым клиентам больше не продаётся. В общем, убила его циска. Может, там и была нехватка производительности, ещё какие-то проблемы — этого я уже никогда не узнаю.
1) на момент принятия решения я не имел данных об аппаратных балансировщиках, тянущих больше 10Гбит/с. Может, сейчас уже есть. Но ценник всё равно будет космический.
2) предположим, что сервер с Haproxy/nginx может тянуть 20Гбит. Ладно! Гуляем на все 40, как Нетфликс!!! Их всё равно надо купить много штук, поставить в стойку, как-то зарезервировать, обеспечить сетью (портами, полосой) на все эти гигабиты. И сделать это на каждом нашем узле — не только в Москве. Много. Дорого. Хреново в обслуживании (просто за счёт количества).
Да, если есть конкретные требования к server affinity, как у JDima, то да, там вариантов нет. Но если задача на прикладном уровне позволяет обойтись без привязки клиента к серверу (а я бы для всех веб-проектов рекомендовал делать без привязки), то нет смысла в «тяжелом» L7-балансировщике.
Да там же всё написано: дорого и ненужно.
Это физика. Балансировщик подключен к свитчу. Можно, конечно, и к двум свитчам подключать, но я не видел смысла это отображать.
Но некоторые элементы этого метода можно перенять и вам. Я так понимаю, у вас всё равно стоит какое-то количество L7-балансировщиков, которые обеспечивают sticky cookie. А вот между ними можно балансировать / резервировать по такой методике, как у нас. Тогда, если между балансерами есть репликация состояний, то всё отработает, как надо.
Речь о парности, которая присуща VRRP, о том, что либо сервер стоит «в запасе», либо работает, как все. В первом случае это экономически неинтересно. Во втором — при переключении нагрузка на выжившего удвоится (100% рост нагрузки). И не важно, сколько у меня серверов — они все разбиты на пары. А вот когда из 4 серверов выбывает 1, то на три оставшихся придётся +33% дополнительной нагрузки. Такую прибавку серверы, скорее всего выдержат. Это не +100%. С увеличением же количества серверов в кластере там ещё лучше получается.
Согласен, но не всегда и не везде.
Согласен.
В принципе, сигналить на роутер можно по-разному: хоть через CLI, хоть через XML. Что выбрать — дело вкуса.
Хотя по документации должно всё работать…
2) Ага! :) И ещё есть несколько трюков — сделаю статью при случае.
Ну, значит всё равно весь трафик через него должен идти. А у нас его очень много. Не как в mail.ru (по донесениям разведки), но порядочно.
Хрюша больше не придёт — нет больше такой функции. Да и когда была, мне про неё гадости рассказывали. Сам попробовать не успел.
Опять же, в регионах нет у нас 6500. И не будет.
Не делайте NAT на Sup2T. Я уже плавал. Больше не хочется. Дело не в производительности. Может быть, как-нить напишу…
Ничего не мешает. Вот только как ограничивать загрузку сервера не более 50%? А то если будет больше 50%, то оставшийся просто не выдержит, и сервис упадёт в полном составе.
Не совсем. IP SLA словит только физическое пропадание сервера (сети). А это маловато будет.Нужно целяться на прикладном уровне. Если есть HTTP-проб, то да. Но как правило, такого нету. Поэтому состояние приложения проверяется на сервере, по большому количеству признаков «здоровья». А дальше — то же: сервер должен как-то сообщить роутеру о своём состоянии. Для этого берём динамический протокол маршрутизации.
Если не нужно проверять на прикладном уровне — тогда да, track.
Во встроенном почтовом клиенте по паролю приложения войти получается. Но хочется-то родное приложение.
Мои действия?
И второй вопрос: а можно сделать «копию» Я.Ключа на втором моём устройстве?
Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.