Здравствуйте, форумчане, сотоварищи!
Возник недавно один вопрос... возможно ли обладая лишь доступом на уровне VPS и, собственно, несколькими VPS (для упрощения возьмем... две) - реализовать собственную CDN? Если да - какими методами? Резонно ли?
Большинство результатов в Google "are irrelevant", да и мнение, собственно, профессионалов, имхо, форумчанам полезнее...
Приглашаю к дискуссии
P.s.: и медальку героя себе лично - надо ведь сформулировать весь пост так, чтоб все же не использовать отсутствующих в укр.раскладке букв = ) _________________ До выхода LiteDiary 0.3.0:парам-пам-пам-пам! Она уже здесь!
Использование аналогов из украинской раскладки не сильно испортит сообщение. Мне с тайской клавой было сложнее.
-----
По теме.
Web-balancing делается на уровне nginx очень просто. Доки по этому поводу в вики nginx есть.
Можно рандомно или по гео-признаку редиректить или на www1 или на www2
Балансираторов от одного и более.
Далее. вариант 2.
2 ns. Каждый из них отдаёт свой IP как А запись. (грабли с кешем dns, успешно наступаем). не RFCшно.
Третий. Общая точка входа. Эта точка входа и осуществляет проксирование сама. Например, на менее загруженный сервер.
точек входа 1+ _________________ сервис DNS | разные http, DNS и прочие утилиты
lazutov
Собственно, идея, скорее имено в "тихой" CDN (ака, той, которая не кричит о себе всему миру, подменяя адрес). Но тут опять же свои "грабли" - определение геопризнака до того, как запрос ушел к PHP или другому обработчику приложения, доступ к базе (рискну предположить, идеал - внешний БД-сервер с удаленкой + кеширование запросов) и... наверное, все. Ближе, получается, вариант 3, верно? _________________ До выхода LiteDiary 0.3.0:парам-пам-пам-пам! Она уже здесь!
lazutov
Собственно, идея, скорее имено в "тихой" CDN (ака, той, которая не кричит о себе всему миру, подменяя адрес). Но тут опять же свои "грабли" - определение геопризнака до того, как запрос ушел к PHP или другому обработчику приложения, доступ к базе (рискну предположить, идеал - внешний БД-сервер с удаленкой + кеширование запросов) и... наверное, все. Ближе, получается, вариант 3, верно?
nginx + geo модуль это и будет определение сервера до передачи запроса обработчику.
Если я правильно понял, то документ берется с $geo.server, где исполняется скрипт и т.д., а для пользователя адрес остается все тем же?
+ пока не дошло, что нужно указать в upstream default.server'а.. документация nginx недостаточно разжевана
Общая цель - ускорение загрузки за счет подбора географически сервера, более удобно связанного с клиентом, но с возможностью, скажем, поддержки нескольких в роли "резервов", чтоб могли подхватить запрос из тех, где не указан сервер.
Опять же, если до меня дошло - метод с nginx данную проблему хорошо решает в распределении нагрузки, но слабо - для геооптимизации (т.к. реально пользователь работает посредством конкретно того сервера, где стоит проксирующий nginx). Впрочем, как применить для сих целей DNS-систему - мне понятно еще менее... боюсь, вовсе нереально _________________ До выхода LiteDiary 0.3.0:парам-пам-пам-пам! Она уже здесь!
Если я правильно понял, то документ берется с $geo.server, где исполняется скрипт и т.д., а для пользователя адрес остается все тем же?
+ пока не дошло, что нужно указать в upstream default.server'а.. документация nginx недостаточно разжевана
Общая цель - ускорение загрузки за счет подбора географически сервера, более удобно связанного с клиентом, но с возможностью, скажем, поддержки нескольких в роли "резервов", чтоб могли подхватить запрос из тех, где не указан сервер.
Опять же, если до меня дошло - метод с nginx данную проблему хорошо решает в распределении нагрузки, но слабо - для геооптимизации (т.к. реально пользователь работает посредством конкретно того сервера, где стоит проксирующий nginx). Впрочем, как применить для сих целей DNS-систему - мне понятно еще менее... боюсь, вовсе нереально
скажем так proxy_pass будет проксировать запрос и адрес останеться всё тотже но трафик будет течь через сервер где nginx, всё верно. Я тут я забыл поправить извиняюсь
можно установить proxy_redirect и тогда будет перебрасывать на другой сервер с адресом скажем www1.example.com который расположен географически ближе. В dns естественно нужно прописать субдомены www1.example.com; www2.example.com; с правильными A записями.
тут указываеться ip-сети пользователей и название групы серверов которым будет отдан на обработку запрос.
В upstream default.server записывают сервер на который пользователь будет переброшен если не найдено соответсвие.
т.е. что бы было понятней пользователь с ip 1.1.1.1 будет переброшен на сервера us, а пользователь 1.1.4.1 будет переброшен на default.
*************************************************************
Вариант с dns лучше тем что адреса остаются идентичными просто пользователю отдаётся A запись географически ближнего сервера, но здесь есть существенный недостаток dns часто кешируется и сложно проверить что именно получит пользователь.
В плане геопривязки это вобщемто не имеет значения мне кажется, американец скорее всего получит адрес американского сервера, а европеец европейского. Но для балансировки нагрузки такой метод негодится потому что распределение будет не равномерным изза кеша.
как это происходит на уровне конфигов bind'a к сожалению не знаю, не было повода в этом разобратся)
Можете описать самое простое решение следующей задачи:
Есть два VDS надо чтобы при выходе одного из них включался второй (дублирование серверов).
Для этого необходим ещё и третий хостинг (от доступности которого будет все зависить)?
Как это можно реализовать (желательно на пальцах)? Задачи ускорения доступа, распределение данных, разделения нагрузки (каждый VDS может держать полную нагрузку на сайт) и т.п. не стоит, главное чтобы непотопляемость сайта увеличилась.
P.S. Я правильно понимаю что это можно реализовать просто указав А записи двух ip адресов в DNS сайта. _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
А браузер выбирает как правило первый или случайный.
А точно что все браузеры после того как первый ip недоступен не попытаются перейти по второму ip в днс? По моему это вполне логичное решение.
lazutov писал(а):
Нормальное решение: Несколько входных точек повышенной надёжности, которые просто проксируют куда надо.
Не понятно как может быть несколько входных точек если ip у нас один?
Второй вопрос где взять эти самые "точки повышенной надежности"? Какой хостинг их может предоставить? И каким образом реализуется проксирование? _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
Welcome to web2.qwerty.name.
You requested http-host: any.test.qwerty.name
Error 404: page not found
Page you requested is unavailable and cannot be found.
Тест2, Тест3: выпало страница не найдена
P.S. Браузер хром. _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
Получается что в балансировке DNS всё сводится только к нескольким А записям к домену?
Нет каких либо dns серверов которые работали бы по тому же принципу что и nginx + geo, т.е. определяли из какой страны пользователь и отдавали одну А запись ближайшего сервера?
Точно. Браузеры не перебирают. Полгода назад мы пытались.
Опять таки все в результате сведется к доступности одного VDS? Есть какой либо хостинг где гарантированно обещают (и дают) аптайм близкий к 100%?
lazutov писал(а):
У входных точек может быть несколько ip. Просто средствами dns.(много А)
А в чем смысл? Получается падение одной входной точки повлечет потерю и трафика с неё? Другими словами несколько входных точек только увеличивают вероятность отказа у пользователя. Получается для отказаустойчевости надо иметь одну точку на непотопляемом хостинге (как я понимаю больших ресурсов от хостинга не требуется, т.к. он просто перенаправляет трафик на другой сервер). _________________ Написание конвекторов, парсеров, интеграции нескольких сайтов (в личку)
Веденин
У меня за 2010-й получается около 99,997%... но опять же, нехорошо как-то зацикливать весь процесс на одном сервере.
+ Опять же, а если падает сервер с базой - при динамическом сервисе - вся система падает автоматом, не так ли? Как справиться? _________________ До выхода LiteDiary 0.3.0:парам-пам-пам-пам! Она уже здесь!
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
