что ето значить??

[VitalVas]

однажды я разгаваривал с одним сисадмином и дошло до мошности сервера и нагрузки на сервер при большой посещаемости и там выскочила такая фраза

якщо більше 15 тис то тільки с балансуванням на вертикальну нагрузку

что ето значить??

[goletsa]

А по русски?

[versus]

однажды я разгаваривал с одним сисадмином и дошло до мошности сервера и нагрузки на сервер при большой посещаемости и там выскочила такая фраза

якщо більше 15 тис то тільки с балансуванням на вертикальну нагрузку

что ето значить??

Ну давай рассуждать логически.
Большой поток пользователей на 1 сервер приводит к тому что функции сервера надо продублировать на еще одном, таким образом мы получаем ферму серверов из одинаковых сервисов, например на 30 серверах будет апач с пхп скриптом. Такое распределение нагрузки называется горизонтальным масштабированием. Если хорошо подумать то запросы пользователей можно кэшировать, часть неизменных данных можно отдавать сразу, без динамической отработки. Поэтому ставим какой то сервис который позволяет нам сократить горизонтальную ферму или нагрузку на нее, за счет кеширования которое происходит до обработки запроса. Получаем вертикальное распределение. Чем больше серверов поставим вертикально тем меньше серверов надо ставить горизонтально, но каждый сервер берет на себе более узкую функциональность, что приводит к тому что приходится продумывать связку и надежность системы.
В нодени как раз вертикально-горизонтальное масштабирование, вы можете ставить сколько угодно горизонтальных серверов-сателитов. Но есть сервер ядра, сервер базы данных, роутеры.
Вот собственно и все заморочки ....

[goletsa]

Хм. У мну сателиты по вертикали еще разделены.
2*PPPoE сервера авторизации на один сервер с NAT'ом и фаерволом.
Раньше было все в одном (PPPoE+NAT вместе на одной машине).

[VitalVas]

давай перейдем на примеры
например, имеем какой то портал - uzhgorod.us
запись в днс
uzhgorod.us.   IN   A   195.225.228.5
uzhgorod.us.   IN   A   195.225.228.6

и в фаерволе на кождом сервере
ipfw -q add 10 allow tcp from any to me 80 setup limit src-addr 1800
ipfw -q add 11 allow tcp from me to any

так правильно???

[versus]

Твой пример это горизонтальгая баллансировка средствами ДНС. Не плохо, но при падении одного сервера, не более 1800 клиентов будет обслуживать.
Я бы сделал чуток по другому. Поставил бы  нжинкс, который делает балансировку на апачи, статику отдавал бы нжинксом. При падении сервера с нжинксом вылезли бы проблемы, но тут как раз можно быстро сменить ДНС на второй сервер(апач+nginx), который бы подхватил работу упавшего бойца. Это самый простой пример
В реальности я бы посмотрел в сторону Heartbeat daemon на www.linux-ha.org, тем самым позволив наращивать горизонтально вэбсервера в звасимости от нагрузки.
Хотя твое решение имеет право на жизнь

[Andrey Zentavr]

По поводу heartbeat есть моя статья на оупеннете:
Создание кластера высокой доступности для XEN с Live миграцией в CentOS 5.3 с использованием VLAN и DRBD.
В этом случае запущенная виртуальная машина находится всегда на одном из нод кластера.

По поводу отказоустойчивости на Фре можно посмотреть в сторону carp

[VitalVas]

у меня есть идея.
если написать скрипт генерации конфига днс для сайта и в него включить проверку сервера, то если сервер или демон на сервере недоступен, то скрипт генерирует новый конфиг для днс ну без
ір того сервера
запустить етот скрипт в кроне, чтоб через каждые Х минут запускался и проверял

конфиг днс приблизительно такой:

Код:

uzhgorod.us.	 1800	  IN	A	195.225.228.5
uzhgorod.us.	 1800	  IN	A	195.225.228.6

и про фаер незабываем(ну если днс глюкнит)

Код:

ipfw -q add 10 allow tcp from any to me 80 setup limit src-addr 1800
ipfw -q add 11 allow tcp from me 80 to any

как такое решения??

[versus]

Дело в том, что обновления ДНС серверов дело медленное, расходится зона примерно за 24 часа, так что при ддосе, ты в любом случае теряешь клиентов, которые находятся на необновленных днсах. Вариант с нжинксом в этом плане дело 2-3 минутда еще и нагрузку выравняет, или хотя бы статику отрелит если апачам совсем плохо будет