- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Друзья,
подскажите пожалуйста пути решения следующей задачи:
Имеем: Сайты (фалы), базу mysql. Все находтся на удаленном хостинге (не выделенный или виртуальный сервер). Два сайта работают с одной общей базой (Битрикс Малый-Бизнес).
Задача: В случае сбоя на одном из сайтов обеспечить быстрое (максимум 10-15 мин) переключение на резервный клон-сайт.
Условия:
1. Резервный клон-сайт должен являться копией основного (актуальность не более суток);
2. Создание и поддержание клона-сайта должно быть автоматическое;
3. Резервный клон-сайт не должен быть доступен в открытом доступе в интернете (как второй сайт);
4. Учитывать ограниченные возможности удаленного хостинга;
5. Использование Бекапов (хостинга или других) не рассматриваем.
Подскажите, как поступить в данном случае?
На выделенном хостинге такое реализовать сложно, ввиду ограничений, которые установил хостер. Как вариант, можно занизить TTL в dns зоне, сделать его скажем 5 минут и менять IP адреса в случае падения одного из серверов. Но такая схема сработает не везде, все зависит от настроек DNS серверов у провайдера клиента. Думаю, что переход на ВПС, как написано выше более реальный вариант решения проблемы.
Как на счёт использования upstream в Nginx? + DNS round-robin
никак. написано же - хостинги не выделенные и не VPS:
Все находтся на удаленном хостинге (не выделенный или виртуальный сервер).
К тому же, VPS для балансировки тоже может упасть.
Учитывая весьма свободные рамки, можно попробовать бекап по расписанию и сервисы dns failover. Например, вот этот http://www.dnsmadeeasy.com/services/dns-failover-system-monitoring/
И, конечно, надо понимать как именно это работает. Быть готовым к несогласованности и пропаданию части данных и тд.
3. Резервный клон-сайт не должен быть доступен в открытом доступе в интернете (как второй сайт);
А что в этом плохого ? Не понятно с какой целью этот пункт возник. Если не хотите усложнять автоматизацию, вполне можно убрать этот пункт.
В самой простой схеме любой, кто догадается подменить IP сайта на резервный, сможет зайти на сайт на резервном хостинге. Ну посмотрит устаревшую информацию и его изменения затрутся при следующем бекапе. Ну и что ?
Спасибо, видимо вы правы. Сейчас использую виртуальный хостинг от таймвеб, но мощный под Битрикс. Естественно нет возможности корректировать работу сервера.
А вот это не скажите. Надо знать где и что заказывать -) 99.999% ТС точно хватит. Лучше не найдёт...
А еще VPS для балансировки не сможет обеспечить ту же скорость открытия сайта, какую обеспечивает хостинг сейчас. хоть на 50 мс, но точно медленнее будет. В качестве резерва еще можно потерпеть, а вот постоянно такое не понравится.
Lodka, никакая полупроводниковая электроника не может работать со скоростью света. Скорость передачи данных ограничена не столько скоростью непосредственно распространения сигнала по волокну, сколько скоростью переключения транзисторов. По крайней мере в географических масштабах европейской части России.
Плюс всевозможные синхронизации, буферизации, избыточность для коррекции и тд и тп всех уровнях передачи данных.
Любое промежуточное оборудование снижает скорость загрузки.
А что в этом плохого ? Не понятно с какой целью этот пункт возник. Если не хотите усложнять автоматизацию, вполне можно убрать этот пункт.
В самой простой схеме любой, кто догадается подменить IP сайта на резервный, сможет зайти на сайт на резервном хостинге. Ну посмотрит устаревшую информацию и его изменения затрутся при следующем бекапе. Ну и что ?
Если будет открыт - получаем дубль сайта. Потом объяснять поисковикам, что это совсем не то, что они подумали. Ну или в robots.txt на резервном сайте можно прописывать запрет, но тогда это уже не копия.
Dr.SEOMAG, ну вот о чем я и пишу : чтобы успешно пользоваться сервисами типа dns failover, нужно понимать что именно они делают.
Дубля сайта не получится. Единственное, что может случится, это поисковик где-то обнаружит ссылку на резервный IP http://12.34.56.78/, но в этом случае виртуальный хостинг обычно отдает затычку, а не ваш резервный сайт.
Lodka, http://80.93.56.188/. Все, они уже побежали.
Не видел, чтобы поисковики без "настояния" администратора посещали IP-адреса.
А на самом деле ситуация вполне стандартная. С такими проблемами как минимум раз в неделю приходят люди, которые ставят панель ISPManager, а она по умолчанию выдаёт сайт и по ip и по домену. В итоге замечают дубли в поисковиках и просят помочь.
Lodka, http://80.93.56.188/. Все, они уже побежали.
Это вы закрыли таким образом?