- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день.
В связи недавними проблема в ovx задумались об отказоустойчивости вэб проекта.
Выбрали простую схему балансировщик и + два сервера расположенных у разного хостера.
С балансировщик пока точно не определись, но есть два варианта haproxy или nginx.
Не понятно как быть с базой mysql и файлами сайтов, как их между серверами обновлять?
Mysql базу настраивать мастер-мастер.
А файлы чем лучше между серверами обновлять/раскидывать, rsync?
Сайтов несколько штук, битрикс, файлов много, трафик не большой, базы не большие окало 1Г.
Спасибо за понимание.
Всегда интересовал вопрос. А если балансировщик перестанет работать, то весь смысл в нескольких серверах за балансировщиком теряется. Т.е. с точки зрения распределния нагрузки с одного сервера на несколько балансировщик подходит, а с точки зрения надёжности по-моему никакого улучшения не будет.
Из простого - TTL поставить поменьше и в случае проблем с первым сервером сразу менять IP в DNS на на IP второго сервера.
Всегда интересовал вопрос. А если балансировщик перестанет работать, то весь смысл в нескольких серверах за балансировщиком теряется. Т.е. с точки зрения распределния нагрузки с одного сервера на несколько балансировщик подходит, а с точки зрения надёжности по-моему никакого улучшения не будет.
Из простого - TTL поставить поменьше и в случае проблем с первым сервером сразу менять IP в DNS на на IP второго сервера.
Шанс возрастает не упасть.
100% структуры отказоустойчивости все равно нет.
cloudflare.com - Load Balancing - можно заюзать. Если вам надо Balancing между серверами по http - трафик не большой, не думаю что дорого будет стоить :)
Что касается mysql - реплика, но надо учитывать особенности которые могут возникнуть.
Файлы можно ( rsync а можно и lrsync) . Можно выбрать дц где все годами работает и не падает.
---------- Добавлено 10.11.2017 в 13:32 ----------
Всегда интересовал вопрос. А если балансировщик перестанет работать, то весь смысл в нескольких серверах за балансировщиком теряется. Т.е. с точки зрения распределния нагрузки с одного сервера на несколько балансировщик подходит, а с точки зрения надёжности по-моему никакого улучшения не будет.
Из простого - TTL поставить поменьше и в случае проблем с первым сервером сразу менять IP в DNS на на IP второго сервера.
Вы правы :) но TC вроде как уже выбрал модель работы.
На самом деле, им надо отказоустойчивость. - это и дешевле и то что надо, в случаи падения одного из серверов.
cloudflare.com - Load Balancing - можно заюзать. Если вам надо Balancing между серверами по http - трафик не большой, не думаю что дорого будет стоить :)
Что касается mysql - реплика, но надо учитывать особенности которые могут возникнуть.
.
Можно насчет особенностей по подробнее?
Можно насчет особенностей по подробнее?
Зачем вам делать репликацию. вы же не от нагрузок спасаетесь. лоадбаланс, мастер-мастер.
самое простое. по моему мнению отказоустойчивость.
Это - ( руки ) ( DNS ) (rsync) (mysqldump) - и схема должна быть такая 1 дц - главный сервер 2 - дц выключенный сервер, на который все переливается, и в случаи падения меняете ip и оживляете на время 2 - сервер в дц. пока не восстановите основной.
Вот и все. 🍿
Можно и по другому сделать. Поднять ноды на promox - например, и там устроить так-же. Основная нода1 - и резервная нода2.
Шанс возрастает не упасть.
С чего он возрастает ? Балансировщик может упасть с тем же шансом, что и основной сервер. В нем смысл, когда система в кластере и запросы по разным машинам распределяются.
Зачем вам делать репликацию. вы же не от нагрузок спасаетесь. лоадбаланс, мастер-мастер.
самое простое. по моему мнению отказоустойчивость.
А как же тогда базу в актуальном состоянии держать?
С чего он возрастает ? Балансировщик может упасть с тем же шансом, что и основной сервер. В нем смысл, когда система в кластере и запросы по разным машинам распределяются.
Пока продумываем стратегию, ну завести два балансера.
А как же тогда базу в актуальном состоянии держать?
А вам надо ежесекундное состояния ? Какая допустимая мера простоя ? при наличии не большого трафика на сайты.
А вам надо ежесекундное состояния ? Какая допустимая мера простоя ? при наличии не большого трафика на сайты.
Планируется на будущее, что будит позже трафика больше и база с файлами вырастит.
Я как понял, вы имели ввиду, держать сервер про запас, и если что быстренько файлы и базу накотить, что бы был минимальный простой, а как же тогда в днс? днс же будит меняться минимум 8-14часов.
Зачем нужен балансировщик если и он упасть может ?
Берёте как и хотели 2 сервера в разных ДЦ и репликацию налаживаете.
А затем берёте на dyn.com тариф за 160 долларов месяц, ,будет одновременно хостинг DNS и лоадбаланс - два IP в записи А указали, настроили и затем сервис сам всё отслеживает - упал один сервер - за секунду перенаправление всё на другой пошло :)