Тут еще стоит проверить и увеличить sysctl net.core.netdev_max_backlog, оно почти везде по дефолту 1000. Можно поднять до 2000. Думаю, что этот лимит на уровне программы и отдельных сокетов не регулируется.
Главное, не забудьте отвязаться от времени dom0, если возьмете xen. Т.е. sysctl -w xen.independent_wallclock=1
И проверьте, какой будет clocksource. Если clocksource будет эмуляцией какого-нибудь аппаратного чипа, то это будет весьма нестабильный источник и не подойдет для высокого стратума.
Теоретически, xen может обеспечивать более качественный источник времени для виртуальной машины - clocksource xen. Он есть в совеременных ядрах линукса. Накладные расходы на передачу времени будут минимальными. В KVM, насколько я знаю, передача часов в виртуальную машину всегда выполняется через эмуляцию.
Но сравнений на практике мы не делали и чужих сравнений я не видел. Поэтому это только теоретические предположения.
Сейчас проблема с DNS-серверами nic.ru, которые обслуживают геодомены в ru, а также *.net.ru. У агавы и свой сайт, и часть клиентских, расположены на ns*.agava.net.ru. Соответственно, из-за nic.ruшной проблемы с зоной net.ru страдают клиенты агавы.
Хостеры могут держать рабочую систему в контейнере openvz или jail для упрощения администрирования. Например, при проблеме с железом перенос контейнера на сервер с совершенно другой конфигурацией может занять всего несколько минут, а перенос загрузочной ОС и перенастройка займут намного больше времени.---------- Добавлено 20.04.2013 в 16:30 ----------
А чего так удивляться? У нашего "соседнего" проекта несколько сотен клиентов на freebsd 4 хостят сайты. Специально для них в виртуальных машинах. Большинство примерно с 2000 года. Имеют выбор - ничего не трогать и использовать то, что есть, или переходить на свежие версии с возможной ловлей багов из-за изменений. Как видите, многие ежегодно решали вопрос в пользу ничего не трогать.
В платном есть, называется Interface customization.---------- Добавлено 22.03.2013 в 19:20 ----------
Это не отменяет утверждения того, что у DDoS-защиты заметная себестоимость. Для бесплатных аккаунтов эту себестоимость оплачивает маркетинговый отдел cloudflare и его платные клиенты.
Собственно, само утверждение про себестоимость имеет смысл рассматривать применительно не к CloudFlare, а к аналогичным сервисам мелкого масштаба. Продавая задешево защиту от падений одновременно с ddos-защитой, такие компании либо полагаются на отсутствует ddos-атак и живут до первых нескольких атак, либо должны иметь хорошие инвестиции в этот продукт, чтобы позволить себе работать в убыток долгий срок набора нормальной клиентской массы.---------- Добавлено 22.03.2013 в 19:24 ----------
Точно. И если на счет собрать - разовые траты вполне могут быть адекватными, то на счет обслуживать - это будет всегда дороже, чем готовое решение от специализирующейся компании.
Про камни cloudflare, как видно, уже рассказали. На более дешевые решения рассчитывать не стоит, т.к. такая услуга идет, как правило, в комплекте с DDoS-защитой и у нее достаточно ощутимая себестоимость. Профессиональные CND дешевле эту услугу не продают, у limeligth и akamai это еще дороже обойдется.
Если вы найдете более дешевое решение от хостера или стартапа, то будете серьезно рисковать получить намного больший простой из-за проблем этого сервиса. Сделать такое и продавать легко. Но сделать так, чтобы работало железно и не ломалось, ломая и вам работу магазинов, будет стоить намного дороже.
Как правило, это относится к шаред-хостингу, где хостер управляет ОС и всеми серверными программами, включая, БД и, соответственно, может настроить бэкапы базы.
С VDS это не совместимо, т.к. в качестве минимальной неделимой услуги здесь выступает целый виртуальный сервер. Внутреннее его устройство - версия базы (кому-то нужна mysql, кому-то postgres), место, где хранятся данные базы - все это зависит от того, как администратор установил и настроил систему. Универсальных методов организации бэкапов БД для всех возможных вариантов ОС и баз данных нет. В принципе, хостеры по заявке клиента могут настроить бэкапы и БД, и какой-то другой части данных сервера, но проще найти хостера, который делает бэкапы системы целиком.
Но, в любом случае, если вы хотите по максимуму защитить данные от потери, бэкапы нужно организовать на не зависящую от хостера площадку - на другого хостера, себе в офис.
У небольшого времени TTL есть проблема - если TTL будет 1 минута, то у посететеля сайта после каждой минуты будут возникать дополнительные задержки на повторный ресолвинг. Получается, что для того, чтобы повысить отказоустойчивость для редких, в общем-то, простоев, нужно будет в той или иной степени ухудшить скорость отдачи страниц. Если TTL увеличивать, то увеличивается процент посетителей, попавших на умерший сервер.
Из плюсов по сравнению с multiple IP, согласен только с одним:
Удешевление репликации - это его следствие.
Геобалансинг от низкого TTL никак не зависит, к плюсам относить бессмысленно.
У multi IP по сравнению с BGP тоже стоимость мизерная, поэтому к плюсом низкого TTL относить не надо.
Не только IE, не забывайте игнорирующих TTL провайдеров и поисковики. Это может быть неприятно припоминать, но это реальность.
Я не встречал таких браузеров, но допускаю, что какие-то редкие экзотические есть. Скорее всего доля таких в общем числе чуть отличается от нуля. Для них, да 50% - это если в сети два хоста и вышел из строя один. Если их больше, то вероятность того, что он окажется в списке первым, уменьшается. На практике сочетают обе схемы - multi IP и небольшой TTL (10 - 60 минут), и исключение недоступного хоста из списка, что позволяет получить практически достижимый максимум. Правда, исключение делается в первую очередь не для предполагаемых проблемных браузеров, а для минимизации задержек на подключение к неотвечающим хостам.
Прямой ответ вы дать не можете. Это можно понять.
Мониторить доступность серверов и выдавать IP в зависимости от доступности - это уже не простое решение, которое каждый мог бы реализовать самостоятельно, и явно сложнее, чем прописать в зоне несколько IP. Хотя в арсенале средств фейловера специалистами это и применяется, но в качестве единественного и все решающего средства это не подходит. Только вместе с другими. Например, DNS-сервер мониторит веб-серверы и отдает списом все IP-адреса, исключая из него недоступные.
Полагаться только на TTL DNS - плохая идея. Ресолвер опрашивает следующий ns-сервер, если во время запроса к DNS не ответил очередной ns-сервер. Браузер в этом никак не участвует. Если браузер получил из кэша своего dns-сервера IP-адрес, который барузеру не ответил, перезапрашивать по DNS браузер не будет, не смотря на любые TTL. В стандартах этого нет, в стандартах есть multiple A-records.
То, что "Все остальное вы придумали" - это допущение, утверждение или вы так припоминаете? Если утверждение, то где подтверждение утверждения? Если допущение, то ладно, допускать можно все-то угодно, и что земля плоская.
Как? Пожалуйста, вкратце опишите как это работало бы и чем было бы лучше классического решения на нескольких A-записях.
То есть, предлагаете считать инженеров этих компаний некомпетентными? Ладно, не буду вам доказывать противное, пусть такими остаются.
