- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
DLag, спасибо за наводку - будут проблему - обращусь
remsys, обязательно почитаю, спасибо
rusevgen добавил 30.12.2008 в 19:15
Searchers, для меня важны именно базы - скрипты будут "знать" куда ломиться, если база отвалилась (днс тут вообще ни при чем)
чисто теоретически пишите сразу в 2-е базы, а читайте всегда с одной...что вам мешает это сделать? Недостаток тут конечно тот что нужно подифицировать все скрипты, где идет запись. Ведь на самом деле чтение к записи идет как 95/5 т.е. особой нагрузки запись делать не будет.
думаю вопрос должен решаться через репликацию.
сделать устойчивую базу я могу вопрос какраз в веб сервере.
BoyStav добавил 30.12.2008 в 21:41
Насколько я понимаю , самая большая проблема будет не в актуальности базы данных , а в смене записей в ДНС , пока по всем разойдется пол дня пройдет.
да это главная для меня проблема.
предположим есть несколько когерентных узлов, которые поддерживают соглассованное состояние как в случае аварии на одном узле перенаправить трафик на другой?
достаточно ли будет просто создать несколько А записей в ДНС для того, чтобы браузер пробовал подключиться к первому рабочему узлу?
решение с общим прокси естественно не устраивает, т.к. может отвалиться узел с самим прокси.
BoyStav добавил 30.12.2008 в 21:46
Существует элементарно, просто выбирайте правильных датацентров. Общий хостинг на VPS - 2008 16 / 66776 99.850%.
Мне всеравно, что общий аптайм может достигать 99.85%, меня интересуют какраз недостающие проценты, в которые в соответствии с законом подласти иногда попадаю. Например тех проблемы с физ сервером это минимум сутки офлайна, что меня не устраивает. Также слеты базы о которых я писал, без ручного вмешательства сайт не завести.
ВСД у меня от РБЦ, думаю в рамках России дергаться к другим не стоит.
Нет такой проблемы, просто правильно выбирайте технологию виртуализации ;)
Не надо городить сложные кластеры для бюджетных проектов. Результат будет отрицательный.
Есть такая проблема, когда береш готовый продукт :)
А на мой взгляд стоит.
BoyStav добавил 30.12.2008 в 21:47
К сожалению, отказоустойчивые решения дешевыми не бывают. Универсальных решений тоже нет.
требования к отказоустойчивости разные бывают
Не бывает идеальных решений, просто есть оптимальные под задачи.
а откуда вообще эти проценты берутся?
чтобы не париться с днсами берется несколько слабеньких фронтендов сразу, все прописываются в днс с них уже проксирование на фронтенд. если еще и очень не большое таймлив у зоны выставить - то при конкретном падении морды можно ее просто выкинуть с днса.
удобно тем, что все "морды" одновременно не лягут, на фронтенде ставить репликацию, и с реплики можно уже отдавать реадонли запросы , у меня три реплики - с трех отдается запросы.
а откуда вообще эти проценты берутся?
мне тоже интересно :)
BoyStav добавил 31.12.2008 в 16:41
чтобы не париться с днсами берется несколько слабеньких фронтендов сразу, все прописываются в днс с них уже проксирование на фронтенд. если еще и очень не большое таймлив у зоны выставить - то при конкретном падении морды можно ее просто выкинуть с днса.
удобно тем, что все "морды" одновременно не лягут, на фронтенде ставить репликацию, и с реплики можно уже отдавать реадонли запросы , у меня три реплики - с трех отдается запросы.
примерно так и хочу, вопрос интересует, если браузер получает несколько IP для домена, как он их использует?
мне тоже интересно :)
ну вот если максимальный срок восстановление одного из критических звеньев будет составлять 24 часа, то сколько доступности сможете в месяц обеспечить?
ну вот если максимальный срок восстановление одного из критических звеньев будет составлять 24 часа, то сколько доступности сможете в месяц обеспечить?
на мой взгляд так 100/30*29
насколько я помню по форуму (да и подпись об этом гласит :)) у вас опыта в решении подобных задач очень много, поделитесь своей экспертизой пожалуйста
а не должно быть критических звеньев. иначе никакого смысла не будет потому что количество отказов при увеличении звеньев растет. в днс для домена достаточно держать пару ай-пи которые ведут на лод балансеры/прокси а уже с них запросы направляюется на вебфарму (кластер). вероятность выпадения ай-пи на которых живут лод балансеры/прокси должна быть минимальной относительно всех остальных звеньев. такая схема обеспечивает стабильность близкую к 100%. стоимость зависит от реализации звеньев и может быть от ~100 до десятков тысяч если не сотен тысяч долларов поскольку она зависит от используемых компонентов (железные или софтверные) и от требоуемой пропускной способности.
на мой взгляд так 100/30*29
а если это будет ломаться три раза в месяц?
ps. а какова вероятность того что это будет ломаться более трех раз в месяц?
kostich добавил 31.12.2008 в 20:24
а не должно быть критических звеньев. иначе никакого смысла не будет потому что количество отказов при увеличении звеньев растет.
Дима, а ты себя в отношении своего бизнеса каким звеном считаешь? Твой бизнес в твоё отсутствие сможет клиентам обещанное обеспечить?
ps. с новым годом 😂