Балансировка нагрузки: основные алгоритмы и методы

[inkvizitor68sl]

А у вас уже появились IP-адреса с возможностью перебрасывания их между локациями )?

[fortyseven]

Мы постоянно модернизируем нашу сеть и как раз работаем над внедрением новых сервисов.
Можно вас попросить боле подробно рассказать о том, что вам требуется?

[inkvizitor68sl]

«Elastic IP», который можно перебрасывать между двумя датацентрами, независимыми по питанию и аплинкам. Вроде hetzner-овского динамического IP, но в России.
Вообще прям щас вряд ли надо, но осенью пригодилось бы в связи с новым ФЗ =)

[fortyseven]

Если вас не затруднит, напишите на [e-mail] поподробнее, что вам требуется. Если вы уже наш клиент, то можем даже попробовать организовать тестирование.

[kbool]

А что за новый ФЗ?

[inkvizitor68sl]

Ну он не то, чтобы новый — я о хранении ПД на российских серверах.

[QtRoS]

Алгоритмы довольно простые, теоретики Computer Science еще не добрались до этой области?

[ximaera]

Это описание у них простое. Легко сказать «сервер выбирается из статической таблицы», вопрос в том, как эту статическую таблицу можно оптимально реализовать.

[dzzh]

Все серверы, которые обрабатывают запросы, должны быть заняты на 100%; желательно не допускать ситуации, когда один из серверов простаивает в ожидании запросов на обработку.

Скорее «нагрузка между серверами должна быть распределена равномерно». Желательно не допускать ситуации, когда серверы нагружены до 100%.

[youROCK]

В подавляющем большинстве случаев загрузка серверов на 100% означает, что вы не сможете обслуживать некоторые запросы пользователей, то есть будете иметь меньший «эффективный аптайм», чем 100%, и очень недовольных пользователей. Поэтому я бы не стал бы формулировать так мягко :).

[vazic]

Стоит добавить к недостаткам DNS Round Robin метода: низкая степень контроля за исполнителями (кэши DNS, игнорирование дополнительных адресов со стороны клиента и т.д.)

[VAE]

Вопрос. Как связаны балансировка нагрузки в кластерах и теория расписаний?

[lubezniy]

Проблема в том, что часто старт проекта начинается с неясности, какова будет посещаемость и как впоследствии поменяются требования. Можно с нуля потратить кучу времени и ресурсов на масштабируемость и получить мёртвый проект, ибо более шустрые конкуренты уже отжали долю рынка, получили фидбэк и перепиливают архитектуру своих проектов на полученные деньги. Можно, таким же образом обеспечив масштабируемость, получить новые требования, из-за чего всё придётся переделывать. В общем, сколько водки ни бери, всё равно два раза бегать делать.

[Sov1et]

Про IPv6 и DNS rr и её тонкости ни слова.